Moving Vert.x repositories into the Eclipse GitHub Organization about eclipse-proposal-wip

[Narigo]

i.e. do people actually use the organization landing page to find a repository for a particular functional area?

The GitHub repositories are ordered by their last change. I can see what parts of Vert.x changed very quickly by looking at the first page. This helps me finding out if I need to incorporate recent changes in codegen, core or something like sql-common in dependent modules/services/clients/etc.

So yes, at least I am using this page from time to time ;)

[cescoffier]

I'm also a power user of the organization page. We have lots of repositories and the fuzzy search field is a must-have feature. I don't want my search result to have items from unrelated projects.

The ordering is also important. Several times a week, I look at modified repositories to analyse the changes / updates (detect breaking changes, see implications). I could do that looking at the e-mails I receive, but I found the org page much more convenient (Yes, I receive too many e-mails).

About the management of the organization, as soon as the Eclipse maintainers are responsive when we want to create a new repository, a label for issues... it would not be an issue.

[vietj]

GitHub provides flexible administration feature that only appears at the organization level based on teams. The team feature allows to share the control between Eclipse and the Project Lead:

• Eclipse is the organization owner : that means only Eclipse can add or remove users at the organization level
• the Project Lead can have less power in a dedicated team that allows him to grant access to a particular repository to a particular user.

I believe this is a good tradeoff that makes everyone happy.

[purplefox]

I'd be strongly against moving further Vert.x repositories under the Eclipse organisation.

We have a lot of repositories in Vert.x and it would be a mess to have them all under the eclipse organisation. Personally I use the landing page a lot for searching and I think others do too.

We also use the vert-x3 organisation to manage our teams including the vertx-committers list which does not currently map to the Eclipse committers.

I suggest a better option is to have a new top level organisation for Vert.x which replaces vert-x3 and brings in vertx-core too.

[michel-kraemer]

So yes, at least I am using this page from time to time ;)

+1 me too. I would definitely miss it.

[maxandersen]

It is a limitation of github that they can't have sub-organizations; we battled the same thing in our Red Hat and JBoss organizations - current result is a mess of various project and organizations split everywhere :)

I think having something like github.com/eclipse- would be the best approach - not just for vert.x, but for any toplevel/notable project organization at eclipse that has the people and community to maintain it.

(I know that vert.x currently are not an eclipse toplevel project - but I think that is something that would make sense too)

Thus having https://github.com/eclipse-vert.x would make sense to me since it really is its own organization, just like any eclipse toplevel project is its own organization.

We could still have github.com/eclipse contain mirrors of all the various repos to make it even easier to find - but those could then be forks of the github.com/ecipse-vert.x repos.

I think that would make the best of both worlds.

[purplefox]

I think having something like github.com/eclipse- would be the best approach

I'd argue that the "eclipse-" part is unnecessary. I don't think it helps the project to have "eclipse" everywhere.

Take a look at google for example. Yes, they have some projects under the "google" organisation but they have others under their own organisation (e.g. kubernetes).

I think Eclipse needs to step away from this "one size fits all", centralised approach and allow projects to flourish without intervening too much. It's the intervention that kills innovation as it means developers waste time on pointless bureacratic tasks instead of developing great software!

[purplefox]

Another example is Red Hat - you won't find all Red Hat projects under a common Red Hat organisation.

E.g.

https://github.com/openshift/
https://github.com/projectodd

(Also note it's not redhat-openshift or redhat-projectodd)

I would say best practice is to allow different github organisations to exist with their own branding.

[purplefox]

I think Eclipse needs to come to terms with the fact that a single organisation can own many brands, not just one. In fact, it's pretty unusual for a large organisation to only have one brand!

[tsegismont]

+1 on Julien's proposal (keep the vertx org with Eclipse as owner)

Besides, I see no point in adding repositories to the Eclipse GitHub
organization if it is admitted that it is already a mess :)

2016-01-20 11:02 GMT+01:00 Tim Fox [email protected]:

I think Eclipse needs to come to terms with the fact that a single
organisation can own many brands, not just one. In fact, it's pretty
unusual for a large organisation to only have one brand!

—
Reply to this email directly or view it on GitHub
#5 (comment)
.

[fjeremic]

Hi Vert.x team,

I've stumbled onto this thread while investigating the possibility of moving our project, Eclipse OpenJ9, into its own organization.

We also use the vert-x3 organisation to manage our teams including the vertx-committers list which does not currently map to the Eclipse committers.

In particular we are interested in getting a little more control over teams within GitHub. We would like to add non-commiters to a read-only team for the organization so that we can assign issues on GitHub to non-committers.

Do you have any experience with this? How has the transition of Vert.x into its on organization changed things? For better, or for worse? Would love to hear some feedback from you as aim to follow a similar path.

Thanks so much for investing the time to help us.

[vietj]

@fjeremic we barely started using a new organisation for eclipse-vertx recently because it took a lot of time to the foundation to get this approved and technically possible (i.e the foundation scripts that syncs the GitHub organisation took a while to be adapted to custom organisation).

For now the only visible benefit is that we have our own Travis job queue that is not shared with all the other Eclipse projects. We haven't yet leveraged the team aspect yet but as soon as we do we can get back to you.

[fjeremic]

Thanks for the swift response. Right! The Travis CI is a nice side-effect of the move. Incidentally I think Eclipse OpenJ9 may have a large blame for consuming so much Travis resource from the Eclipse organization projects, so us moving to a new organization will benefit everyone else.

Looking forward to any updates w.r.t. the team aspect once you get there. Thanks again!