Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-25 Thread Theo Chatzimichos
On Saturday 22 January 2011 20:06:06 Sebastian Pipping wrote:
 On 01/22/11 13:32, Theo Chatzimichos wrote:
  Well, the distinction for unofficial/official overlays happen mostly in
  layman -L, I don't think users pay attention to our git repo list.
  Furthermore, I got at least three requests from developers to move their
  repo from user/ to dev/ (same problem when devs retired). This
  distinction doesn't make any sense.
 
 Three request over what time?  Compared to a screen height of user repos
 created, maybe that's not much.
 
 
 
 Sebastian

I'm sorry I don't share your point. I think I was quite clear, the 
user/developer distinction (or better, the unofficial/official overlay) should 
happen in layman list and in overlays website, not in gitolite. Take a look at 
the current list in gitweb and tell me honestly how clear and distinct is that 
thing for you. For the record:
the following overlays should move from dev/ to user/:
b33fc0d3, hawking, uberlord, welp
the following should move from user/ to dev/:
dilfridge
at least two people with user/ overlays are going to be gentoo devs soon
and last but not least, smithdanea overlay is useless because c1pher has a dev 
overlay as well now
not to mention the proj/ list.
And now, imagine the state of the user/ dev/ list mess in, say, two or five 
years
-- 
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)

2011-01-25 Thread Robin H. Johnson
On Wed, Jan 26, 2011 at 12:02:16AM +0200, Theo Chatzimichos wrote:
 And now, imagine the state of the user/ dev/ list mess in, say, two or five 
 years
So you're in favour of making it 'people/' and just distinguishing in
the descriptions and Layman?

-- 
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


pgpvVuVxDow1z.pgp
Description: PGP signature


Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-25 Thread Tomáš Chvátal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dne 25.1.2011 23:08, Robin H. Johnson napsal(a):
 On Wed, Jan 26, 2011 at 12:02:16AM +0200, Theo Chatzimichos wrote:
 And now, imagine the state of the user/ dev/ list mess in, say, two or five 
 years
 So you're in favour of making it 'people/' and just distinguishing in
 the descriptions and Layman?
 
Could you guys do it like mammals/

Kthx :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0/SrsACgkQHB6c3gNBRYc6aQCgnWhn+TpaL2ZridSW21wernJL
ZQIAoKhqrbD28kGr4BtV/kBRIGAVhsm7
=AU/O
-END PGP SIGNATURE-



Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-25 Thread Alec Warner
like on the discovery channel?

-A

2011/1/25 Tomáš Chvátal scarab...@gentoo.org:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Dne 25.1.2011 23:08, Robin H. Johnson napsal(a):
 On Wed, Jan 26, 2011 at 12:02:16AM +0200, Theo Chatzimichos wrote:
 And now, imagine the state of the user/ dev/ list mess in, say, two or five
 years
 So you're in favour of making it 'people/' and just distinguishing in
 the descriptions and Layman?

 Could you guys do it like mammals/

 Kthx :)
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.17 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAk0/SrsACgkQHB6c3gNBRYc6aQCgnWhn+TpaL2ZridSW21wernJL
 ZQIAoKhqrbD28kGr4BtV/kBRIGAVhsm7
 =AU/O
 -END PGP SIGNATURE-





Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-22 Thread Robin H. Johnson
On Sat, Jan 22, 2011 at 04:38:49AM +0200, 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:
Yes, they will be merging, but not for many months. What _DO_ need, is
getting the namespaces to be identical as soon as possible, and
preventing namespace collisions for anything that gets added.

Two overall comments about your proposal.
1. 
We EXPLICITLY need a location for private repositories.
- infra: for critical system data [1]
- foundation: for legal tracking, personal, financial information
- PR project: I don't know what they have in there. I've never looked at
  their private repo.

The current breakdown of private repos:
Infra: 2
Foundation: 0, but 2 requested
PR: 1

 source
  - portage-main.git
  - portage-history.git
 infra (or sysadmin)
  - (repo1).git 
  - (repo2).git
  - ...
- I don't think that infra should be a toplevel here. As much as we
  intend to use repos, this is pollution of the namespace.

 overlay
  - project (instead of proj)
- sunrise.git
- kde.git
- ...
  - personal (merge dev/  user/)
- aballier.git
- alexxy.git
- ...
- Some of the developer+user repos are NOT overlays, but Gentoo-specific
  code/applications.
- On one hand, I would like user repositories to have a separate
  namespace, so that other users realize a given repo is NOT from a
  developer. 
  - On the other side, what do we do when a user with a repo becomes a
developer (and when they retire?)

 website
  - blogs.git
  - planet.git
  - forums.git
  - gstats.git
  - packages.git
  - www.git (the gentoo cvs repo)
  - ...
These are projects, why not include them there?

 project (includes SOC projects, forks, gentoo projects etc)
  - devmanual.git
  - portage.git
  - ...
devmanual IS a website...

How are you differentiating project vs. website?

[1] We intend on having public infra repos as well, and just having the
fewest private repos.

-- 
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)

2011-01-22 Thread Michał Górny
On Fri, 21 Jan 2011 22:20:27 -0600
Donnie Berkholz dberkh...@gentoo.org wrote:

 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/.

Yeah, that'd be a good idea for the concept of repositories.

- repos/project/gentoo.git
- repos/project/sunrise.git
etc.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-22 Thread Theo Chatzimichos
On Saturday 22 January 2011 10:55:19 Robin H. Johnson wrote:
 1.
 We EXPLICITLY need a location for private repositories.

didn't know that, so i guess the private dir should be:
private
 - infra
   - (infrapriv1).git
   - (infrapriv2).git
 - foundation
   - (foundpriv1).git
   - (foundpriv2).git
 - pr
   - 
 
 - Some of the developer+user repos are NOT overlays, but Gentoo-specific
   code/applications.

These DON'T belong here, they should go to project/

 - On one hand, I would like user repositories to have a separate
   namespace, so that other users realize a given repo is NOT from a
   developer.
   - On the other side, what do we do when a user with a repo becomes a
   developer (and when they retire?)
 

Well, the distinction for unofficial/official overlays happen mostly in layman 
-L, I don't think users pay attention to our git repo list. Furthermore, I got 
at least three requests from developers to move their repo from user/ to dev/ 
(same problem when devs retired). This distinction doesn't make any sense.

 
 These are projects, why not include them there?


All of the above are *.gentoo.org subdomains
 
  project (includes SOC projects, forks, gentoo projects etc)
  
   - devmanual.git
   - portage.git
   - ...
 
 devmanual IS a website...
 
 How are you differentiating project vs. website?

devmanual should go to website/, you are right. In project/ belongs anything 
that is not a *.g.o subdomain, and is not an overlay (SOC projects, upstream 
projects (portage, gorg, rbot*, znurt), forks (gitolite-gentoo))

 
 [1] We intend on having public infra repos as well, and just having the
 fewest private repos.

Send them to project/ as well ;)

-- 
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)

2011-01-22 Thread Theo Chatzimichos
On Saturday 22 January 2011 06:20:27 Donnie Berkholz wrote:
 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.

And I don't see a reason to merge the huge overlays list with the official 
gentoo tree. They are totally different things, and a future alternative to 
viewvc in sources.gentoo.org (maybe trac-git) should reflect that. If we show 
a huge list with ebuild repos to public (especially to new to gentoo) without 
separating the official tree (including user/unofficial/bad-shaped ones), I 
suppose we'll give the impression we are like debian, where the user needs the 
multimedia overlay to get multimedia ebuilds, or the kde overlay to install 
kde.

For the second part of your question, Ryan's responce is perfect.
-- 
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)

2011-01-22 Thread Alexey Shvetsov
Hi all!

Why not use redmine as sources.gentoo.org?

2011/1/22 Theo Chatzimichos tampak...@gentoo.org:
 On Saturday 22 January 2011 06:20:27 Donnie Berkholz wrote:
 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.

 And I don't see a reason to merge the huge overlays list with the official
 gentoo tree. They are totally different things, and a future alternative to
 viewvc in sources.gentoo.org (maybe trac-git) should reflect that. If we show
 a huge list with ebuild repos to public (especially to new to gentoo) without
 separating the official tree (including user/unofficial/bad-shaped ones), I
 suppose we'll give the impression we are like debian, where the user needs the
 multimedia overlay to get multimedia ebuilds, or the kde overlay to install
 kde.

 For the second part of your question, Ryan's responce is perfect.
 --
 Theo Chatzimichos (tampakrap)
 Gentoo KDE/Qt, Planet, Overlays




-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru



Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-22 Thread Jorge Manuel B. S. Vicetto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22-01-2011 03:20, Donnie Berkholz wrote:
 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
...

 overlay
  - project (instead of proj)
- sunrise.git
- kde.git
- ...
  - personal (merge dev/  user/)
- aballier.git
- alexxy.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.

I think a distinction between tree and project overlays can be useful in
case we ever consider splitting the main tree. In that case, our new
tree would be composed of all the split repos under tree and users
would have an easy way to distinguish between the tree and project
overlays.

We could even provide the ability for users to have just some of the
split repos and thus not require the complete tree.


- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNOvOLAAoJEC8ZTXQF1qEP924P/2dbxlK8m3y0k4/ArQojeJH7
9HY3NzMImIuIW44kcdGhEj6+bJDEPGTz1Pb1zGrNMSxNYgrxrXYkEKEWldNYszm7
TNqQvm+Pl9D39ckjjDzV+zMfKZQn9UtM3MCTOw4ozWZynSLGajkpZK6Cp4BIiOjF
JiPi+Q8zSw/Xc8umLxK4ZfWy4n4WhLDbJgxO8ws+s27iSlQemJhqlOmCw1nMAcyB
FPlf1cyMa0MxUStqHWzJ0MBtYOfkxoSNvnXAoVl47DGPbOagdSSWkbbmx5p6vn2C
HpJ/xNfJkDoPa6DPrbBdQtmiay3A72fkokwLSFKMvNhMjDMeMhR30IPxDkrRf/ls
faIK7FKeJbh/sWr0XgBVR5rsASSQkor647DbjT04/v+g9HN/bB9IxmYY9hVC66aw
+j0gph07zTuXUAHDcqqSnMxlr3MGril+mAVXf+ne2N6emrP88K2plnSGc5LmUfyy
i+eEfb5UBTxfBfmyollKArVS9djzKveKLiVgIn1ga6kyj7JGYiDZnJTOfHJ1sfdc
R8dti5qyqQUruzmjkEeGQEMBpawIh/ZYY3LDfh7MaDkLjLScdVUHgZDipn+QjIUx
lliDjRK5sa1S4WWojK0t/gd3ikW/YrXQRHpLo9EOtMzkRfR9FSbFv+ew8ud5RlyN
eIQrF7smR0LCOMF1/mzj
=ytaq
-END PGP SIGNATURE-



Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-22 Thread Theo Chatzimichos
On Saturday 22 January 2011 16:58:38 Alexey Shvetsov wrote:
 Hi all!
 
 Why not use redmine as sources.gentoo.org?

idl0r installed trac-git for git.overlays, it needs some testing before 
starting to redesign the overlays webpages (ETA 1 month due to my exams) If we 
decide that it doesn't suit our needs we'll proceed in trying something else, 
but this is totally offtopic, please stick to the topic.
-- 
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)

2011-01-22 Thread Jorge Manuel B. S. Vicetto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22-01-2011 11:32, Theo Chatzimichos wrote:
 On Saturday 22 January 2011 10:55:19 Robin H. Johnson wrote:
 1.
 We EXPLICITLY need a location for private repositories.
 
 didn't know that, so i guess the private dir should be:
 private
  - infra
- (infrapriv1).git
- (infrapriv2).git
  - foundation
- (foundpriv1).git
- (foundpriv2).git
  - pr
- 
  
 - Some of the developer+user repos are NOT overlays, but Gentoo-specific
   code/applications.
 
 These DON'T belong here, they should go to project/

Why not provide a tree for overlays and another for application
repositories?

 - On one hand, I would like user repositories to have a separate
   namespace, so that other users realize a given repo is NOT from a
   developer.
   - On the other side, what do we do when a user with a repo becomes a
  developer (and when they retire?)

 
 Well, the distinction for unofficial/official overlays happen mostly in 
 layman 
 -L, I don't think users pay attention to our git repo list. Furthermore, I 
 got 
 at least three requests from developers to move their repo from user/ to dev/ 
 (same problem when devs retired). This distinction doesn't make any sense.

Instead of relying on the name space for such a distinction, I propose
we use a label for that. Preferably we should have an automatic system
to produce the label and have it present on any online repo browsers
(gitweb?) and on project management apps (redmine?) so that users have
no doubt when looking at projects.gentoo.org / overlays.gentoo.org about
the type of a repo. The label to distinguish between developers and
non-developers repos could take advantage of the ldap info. We could
also use labels for the status of a project like we're already doing on
layman.

With the above in mind and some of the suggestions in the other emails,
what about the following structure:


tree

 - core-portage-tree.git
 - core-portage-historical-tree.git

 (possibly some day)
 - gnome.git
 - kde.git
 - sci.git
 - x11.git
 (split profiles, keywords(?))
 - profiles.git


overlay

 - project (do we want to support non-gentoo projects?)
. gnome.git
. kde.git
. sci.git
. sunrise.git
. external project a*
. ...

 - individual (we need to decide whether we want to host and the legal
costs of hosting non-gentoo individual's or project's repos)
. aballier.git
. alexxy.git
. user a*
. ...


project

 - pages (project web pages, but not applications code source like
forums, blogs or PMS)

. main-site.git (split from the current gentoo repo)
. gentoo-project.git (should we split the current gentoo repo?)
. devmanual.git

 - repositories

. project (tied to projects)

  ^ gentoo-forums.git
  ^ gentoo-blogs.git
  ^ gitolite-gentoo
  ^ gstats.git
  ^ packages.git
  ^ planet.git
  ^ portage.git
  ^ pms.git
  ^ releng.git

. individual (work of one or more individuals not tied to any projects)

  ^ portage-utils.git (not tied to any project afaik)
  ^ layman.git
  ^ rbot-gentoo (is it tied to any project?)
  ^ cool new toy for Gentoo done by devs A and B

  ^ soc (include individual soc projects here) (would it make sense
to organize by year?)

' soc project 1
' soc project 2


private

 - foundation
. legal
. finances
. ...

 - infra
. infra 1
. infra 2
. ...

 - pr
. pr 1
. pr 2
. ...


This design includes 4 top-level labels: tree, overlay, project and private:
 * the tree sub-tree should be used for the Portage tree, it's history
and any future trees we choose to have.
 * the overlay sub-tree should be used to host repositories to be used
as overlays.
 * the project sub-tree should be used to host the web pages and sites
and all the repositories for applications / tools.
 * the private sub-tree should be used for private repositories that
cannot be exposed to the public.


- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNOv+zAAoJEC8ZTXQF1qEPp9EP/AvFRbVsYQHcik4PMMFdwHPO
3vCXl2M0JENah/HBIM7cMigt1KWmk8jPJ4QOdARnFb2rVy9nDbycIzKYhHotg/aO
Bh7euJdLj1jxI3DKz1kZCj++DXQyZ0clzBde/c+sYWfw/1bGruRuZoAqr5Tbtkd4
4h6YV2bCHgeJUjUpC/7+K6M1/UNW7MwhdJC9cViLXyZ+O04fGSNZ5g/V7CCQtrE4
oMDodPgmfjwdmp9AqsA6ejVswkhuMbL8KyHS3kEBQXABugQpGnwVnY48KI2oi0yv
4oqa6cv+A6F9hoSrfHk9dytMdegAHtuFmq/70nnLBwVvljrdyGackAJj51oAtLgW
6tZDOGp6ZsjzsruSS3Keh4V2wFRz7Uejjkhkn/QuYMO86QyX3QA0eN9dce/HuOEv
zpbgZf3qvVvZ/zFnJw48sYNogfeb+CSQqs1pqRCjLwhShg1TcrBYYldiRvhxKNXl
SNBBUQDKSiorLGLnM6T23QEH/hEoVVjH6Z6D/09F0MODpwdv0H+iMJkUIGg1iv7G
WladznFgBg/gHjLB15Aq0Ux7eGwd6uoJ1Mm3zt0KbuO14udYgAbW6JvLw2JF7DSV
Y5njptBYPTUHx7Oj15LtzrN6RUQMnN/fLM8/VoBVrSb5dnXIdYWwCerL3JzkFsiH

Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-22 Thread Theo Chatzimichos
On Saturday 22 January 2011 18:02:59 Jorge Manuel B. S. Vicetto wrote: 
 Why not provide a tree for overlays and another for application
 repositories?

You just repeated my proposal, with the only difference I splitted project 
from website :P
-- 
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)

2011-01-22 Thread Sebastian Pipping
On 01/22/11 13:32, Theo Chatzimichos wrote:
 Well, the distinction for unofficial/official overlays happen mostly in 
 layman 
 -L, I don't think users pay attention to our git repo list. Furthermore, I 
 got 
 at least three requests from developers to move their repo from user/ to dev/ 
 (same problem when devs retired). This distinction doesn't make any sense.

Three request over what time?  Compared to a screen height of user repos
created, maybe that's not much.



Sebastian



Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-22 Thread Sebastian Pipping
On 01/22/11 09:55, Robin H. Johnson wrote:
 - On one hand, I would like user repositories to have a separate
   namespace, so that other users realize a given repo is NOT from a
   developer. 

Seconding that.


   - On the other side, what do we do when a user with a repo becomes a
   developer (and when they retire?)

To avoid a move, you'd have to give away distinction.  To be able to do
path-based distinction, you have to move on status updates.  It seems
that you cannot have both at the same time.



Sebastian



Re: [gentoo-dev] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-22 Thread Robin H. Johnson
On Sat, Jan 22, 2011 at 03:02:59PM -0100, Jorge Manuel B. S. Vicetto wrote:
  Well, the distinction for unofficial/official overlays happen mostly in 
  layman 
  -L, I don't think users pay attention to our git repo list. Furthermore, I 
  got 
  at least three requests from developers to move their repo from user/ to 
  dev/ 
  (same problem when devs retired). This distinction doesn't make any sense.
 Instead of relying on the name space for such a distinction, I propose
 we use a label for that. Preferably we should have an automatic system
 to produce the label and have it present on any online repo browsers
 (gitweb?) and on project management apps (redmine?) so that users have
 no doubt when looking at projects.gentoo.org / overlays.gentoo.org about
 the type of a repo. The label to distinguish between developers and
 non-developers repos could take advantage of the ldap info. We could
 also use labels for the status of a project like we're already doing on
 layman.
The existence of labels is completely irrelevant to the actual PATH to
the repos, of which there can be only one, and changing it later is
going to upset people.

-- 
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)

2011-01-21 Thread Donnie Berkholz
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)

2011-01-21 Thread Robin H. Johnson
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)

2011-01-21 Thread Sebastian Pipping
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] Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

2011-01-21 Thread Theo Chatzimichos
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)

2011-01-21 Thread Donnie Berkholz
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