FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 01-22-2011, 08:54 AM
Ryan Hill
 
Default Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

On Fri, 21 Jan 2011 22:20:27 -0600
Donnie Berkholz <dberkholz@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/. 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.

Readability? It's already hard to find the repo you're looking for in that
huge list. I wouldn't want to see them mixed.


--
fonts, gcc-porting, it makes no sense how it makes no sense
toolchain, wxwidgets but i'll take it free anytime
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 
Old 01-22-2011, 08:54 AM
Michał Górny
 
Default Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

On Fri, 21 Jan 2011 22:20:27 -0600
Donnie Berkholz <dberkholz@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
 
Old 01-22-2011, 11:32 AM
Theo Chatzimichos
 
Default Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

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
 
Old 01-22-2011, 11:48 AM
Theo Chatzimichos
 
Default Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.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
 
Old 01-22-2011, 01:58 PM
Alexey Shvetsov
 
Default Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

Hi all!

Why not use redmine as sources.gentoo.org?

2011/1/22 Theo Chatzimichos <tampakrap@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:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru
 
Old 01-22-2011, 02:11 PM
"Jorge Manuel B. S. Vicetto"
 
Default Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

-----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+bJDEPGTz1Pb1zGrNMSxNYgrxrX YkEKEWldNYszm7
TNqQvm+Pl9D39ckjjDzV+zMfKZQn9UtM3MCTOw4ozWZynSLGaj kpZK6Cp4BIiOjF
JiPi+Q8zSw/Xc8umLxK4ZfWy4n4WhLDbJgxO8ws+s27iSlQemJhqlOmCw1nMA cyB
FPlf1cyMa0MxUStqHWzJ0MBtYOfkxoSNvnXAoVl47DGPbOagdS SWkbbmx5p6vn2C
HpJ/xNfJkDoPa6DPrbBdQtmiay3A72fkokwLSFKMvNhMjDMeMhR30I PxDkrRf/ls
faIK7FKeJbh/sWr0XgBVR5rsASSQkor647DbjT04/v+g9HN/bB9IxmYY9hVC66aw
+j0gph07zTuXUAHDcqqSnMxlr3MGril+mAVXf+ne2N6emrP88K 2plnSGc5LmUfyy
i+eEfb5UBTxfBfmyollKArVS9djzKveKLiVgIn1ga6kyj7JGYi DZnJTOfHJ1sfdc
R8dti5qyqQUruzmjkEeGQEMBpawIh/ZYY3LDfh7MaDkLjLScdVUHgZDipn+QjIUx
lliDjRK5sa1S4WWojK0t/gd3ikW/YrXQRHpLo9EOtMzkRfR9FSbFv+ew8ud5RlyN
eIQrF7smR0LCOMF1/mzj
=ytaq
-----END PGP SIGNATURE-----
 
Old 01-22-2011, 02:18 PM
Theo Chatzimichos
 
Default Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

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
 
Old 01-22-2011, 03:02 PM
"Jorge Manuel B. S. Vicetto"
 
Default Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

-----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
oMDodPgmfjwdmp9AqsA6ejVswkhuMbL8KyHS3kEBQXABugQpGn wVnY48KI2oi0yv
4oqa6cv+A6F9hoSrfHk9dytMdegAHtuFmq/70nnLBwVvljrdyGackAJj51oAtLgW
6tZDOGp6ZsjzsruSS3Keh4V2wFRz7Uejjkhkn/QuYMO86QyX3QA0eN9dce/HuOEv
zpbgZf3qvVvZ/zFnJw48sYNogfeb+CSQqs1pqRCjLwhShg1TcrBYYldiRvhxKNX l
SNBBUQDKSiorLGLnM6T23QEH/hEoVVjH6Z6D/09F0MODpwdv0H+iMJkUIGg1iv7G
WladznFgBg/gHjLB15Aq0Ux7eGwd6uoJ1Mm3zt0KbuO14udYgAbW6JvLw2JF7 DSV
Y5njptBYPTUHx7Oj15LtzrN6RUQMnN/fLM8/VoBVrSb5dnXIdYWwCerL3JzkFsiH
++qWiSS9cyGfqSsJ1r03
=gzPb
-----END PGP SIGNATURE-----
 
Old 01-22-2011, 03:15 PM
Theo Chatzimichos
 
Default Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

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
 
Old 01-22-2011, 04:24 PM
Duncan
 
Default Upcoming changes to hosting of Git repos on git.gentoo.org (NOT overlays.git.gentoo.org)

Theo Chatzimichos posted on Sat, 22 Jan 2011 14:32:34 +0200 as excerpted:

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

Agreed with the layman distinction being the practical one for those using
it. However, for site browsers the distinction could still be useful, and
I prefer it in the filesystem layout rather than as a label.

Does the symlink concept work? If so, what about a generic "people"
subtree, with dev and user either at the same level or inside people,
along with the list. Then simply symlink the individual repos to either
dev or user as appropriate (or only have the dev subcase/symlink, so
people can choose either dev specifically, or all users including devs).
Layman could use the generic people path regardless so the path never
changes, and its user/dev description could be updated along with the
symlinks. Meanwhile, site browsers could choose to browse the generic
version or the user/dev specific listings, as they wished.

Tho with layman being the interface most will see and use in general,
labels in the browser interface would probably do. I just prefer the
filesystem layout distinction, especially if it's as trivial as managing a
few symlinks.

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

Thread Tools




All times are GMT. The time now is 10:17 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org