[Vote] Submodules vs Aggregation of some repositories

[hammett]

Option 1: Create a master project that include all other ones as submodules
Option 2: Aggregate some as suggested by Krzysztof

Please cast your vote.

For context:
[0] http://groups.google.com/group/castle-project-devel/msg/dee4a8492a09bbec
[1] http://groups.google.com/group/castle-project-devel/msg/ccf955d79eb54db0
[2] http://groups.google.com/group/castle-project-devel/msg/264f5e6cb3359a0c

--
Cheers,
hammett
http://hammett.castleproject.org/

[Ayende Rahien]

Submodules are bad, in my experience. They result in a cloned repository that can't immediately be used without extra work, that is additional support cost

I am using git subtree to handle those things, and it works pretty nicely.

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

[hammett]

Okay, rephrasing the options:

Option 1: Create a master project that include all other ones as git-subtrees

Option 2: Aggregate some as suggested by Krzysztof

On Thu, Jun 23, 2011 at 11:25 AM, Ayende Rahien <aye...@ayende.com> wrote:
> Submodules are bad, in my experience. They result in a cloned repository
> that can't immediately be used without extra work, that is additional
> support cost
> I am using git subtree to handle those things, and it works pretty nicely.

[Berke Sokhan]

Both are better than the current for usability IMHO. But,

+1 for Option 1
(if I get the right to vote)

and I hope Option 1 will not cause a familiar never-ending-castle-1.0-RC case :)

2011/6/23 hammett <ham...@gmail.com>

Cheers,
hammett
http://hammett.castleproject.org/

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

--
Berke SOKHAN.

http://twitter.com/berkesokhan
http://blog.berkesokhan.com
http://www.birliktegelistir.com/editors.aspx

[Henrik]

Another option - teamcity build dependencies + automate the running of
tests with e.g. openwrap which builds packages as a part of the
process?

[Henrik]

...that's not to say that Krzysztof's ideas about merging are bad, I'm
all for those merges also.

[hammett]

That doesn't solve the local build problems. Let's try to keep this
thread on topic (which is to say, for vote only).

> --
> You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
>
>

--
Cheers,
hammett
http://hammett.castleproject.org/

[Henry Conceição]

+ 1 for opt 1

Cheers,
Henry Conceição

[hammett]

+1 for #2

[G. Richard Bellamy]

I know you want this thread to be a vote on one option or another, but I
think there's a valid third option - which is a combination of both a
single integration repo using git-subtrees, and an appropriate
aggregation of projects.

Given the above: +1 for #1.

-rb

On 6/23/2011 3:13 PM, hammett wrote:
> +1 for #2
>
>

[Alex Henderson]

Option #2 +1

Think both are good, but #2 would remove more pain for me then #1 I think as a Castle "stack" consumer.

[Kelly Leahy]

#1 +1   -- if I get a vote ;)

I also second Oren's comments about submodules - they are an absolute nightmare.

I'm confused as to why Alex thinks that #2 would improve the experience as a castle "consumer".  It doesn't seem like to a "consumer" you'd have any idea which of these choices was selected as the 'winner'.

Perhaps you could elaborate, Alex?

Kelly

[John Simons]

I need some clarification on opt1, is this master repository only for when we need to do some integration tests?

So, we would keep on using the current repositories as we are now, but if we run into integration issues that are hard to debug we then would pull the "master repository", is this what you mean by opt 1?

Cheers

John

---

From: hammett <ham...@gmail.com>
To: castle-pro...@googlegroups.com
Sent: Friday, 24 June 2011 5:14 AM
Subject: Re: [Vote] Submodules vs Aggregation of some repositories

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.

To unsubscribe from this group, send email to castle-project-devel+unsub...@googlegroups.com.

[hammett]

Correct. The master would be the one you'd use to build/test
everything at once.

> castle-project-d...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to

> castle-project-d...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>

--
Cheers,
hammett
http://hammett.castleproject.org/

[John Simons]

So if this is the case, why wouldn't the developer that is investigating integration issues create his own "master repository" locally and deal with the issue that way?

Also,

I see benefits in both options.

To me merging more projects is a must, IMO Castle should aim at only having 4 projects to maintain:

- AR

- MR

- Windsor

- Core

All others should be moved to Castle Contrib.

Cheers

John

---

From: hammett <ham...@gmail.com>
To: castle-pro...@googlegroups.com

Sent: Friday, 24 June 2011 9:53 AM

> castle-project-devel+unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to

> castle-project-devel+unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>



--
Cheers,
hammett
http://hammett.castleproject.org/

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.

To unsubscribe from this group, send email to castle-project-devel+unsub...@googlegroups.com.

[hammett]

As mentioned before, let's keep this thread on topic.

On Thu, Jun 23, 2011 at 5:06 PM, John Simons <johnsi...@yahoo.com.au> wrote:
> So if this is the case, why wouldn't the developer that is investigating
> integration issues create his own "master repository" locally and deal with
> the issue that way?

[Berke Sokhan]

I think the problem is, struggling to solve those integration problems when you try to use them, but not when you break them while developing.

Remember the classic graph, that tells you solve bugs early in the stage of development, it would be more hard/costly to solve a case further on development.

Especially for the user-developer, not the orginal-breaker-developer.

And to note, I assumed that Option #1 reqiures the master repo will be updated for each of its components commit/pushes, am I right?

2011/6/24 John Simons <johnsi...@yahoo.com.au>

To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

--

[Berke Sokhan]

Sorry, maybe people need a different thread for discussing options' definitions/scopes to better understand what is intended.

2011/6/24 hammett <ham...@gmail.com>

Cheers,
hammett
http://hammett.castleproject.org/

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.

To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

--

[Alex Henderson]

Perhaps I'm wrong - but I was thinking with #1

Initially #1 may not always build.

I have everything, including monorail 2, 3 etc. ?

I visit github, there's still a pile of repositories to wade through (as a newcomer to Castle)

With #2

We end up with less repositories in github

For each of those repo's it's likely they will always build when checked out.

As part of #2 there is some time taken to evaluate some of the existing projects and apply some common sense i.e. moving binding into monorail, doing something about projects like template engine / pagination, purging some of the projects without mind share like scheduler (maybe just move them to a single repo called attic?)

To me at least doing #2 then #1 made logical sense to me - and some of that rationalization/grouping occurring in #2 would make it easier as a consumer of the castle stack (easier to maintain a mental model when there are less repositories and the inter-dependencies are clear - similar projects are grouped sensibly, less nuget/openwrap packages etc.)

I'm probably way off base here as I haven't done a lot with the castle code base in the last 6 months for client projects, but that was certainly the way I felt last time I did attempt to build everything together.

Cheers,

Alex

[Craig Neuwirt]

+1 for #2
Although I would put Castle.Components.Binder into Castle.Core and not Castle.Monorail

[Markus Zywitza]

+1 for both:

#2: Merging projects
#1: Single additional project for integration issues

-Markus

[hammett]

Vote results

binding
Option [1] 3 votes
Option [2] 3 votes

nonbinding
Option [1] 2 votes
Option [2] 1 vote

We will need to either wait for an untie vote or go back and re-think
the options.

[Jonathon Rossi]

I know this is meant to be a vote only thread, but before I cast a binding vote (which will change things from being tied 3-3), I need a bit more information.

I read the Pro Git page on subtrees but still find it confusing how pushing upstream will work for a subtree. We also have the scenario where a non-committer wants to provide a patch back to us so they will still need to fork one or more of the base repositories, which will mean the subtree based repo will not work unless they also make changes in that cloned repo to point to their forked repo. If we promote users to clone the super-repo rather than the individual ones, then we'll be requiring users to deal with more complexity of this type of git set up.

Is there much need to maintain a super-repo of the official masters in github, when we could just provide a script to clone/pull all the existing repos into the current directory. TeamCity can also easily be set up to pull from multiple git repositories to perform an build across all projects. I do understand we'll need a script to run the build scripts of each tree and copy the dependencies over to the next tree before running the build script.

Because users still need to fork each repository they want to commit to, I think it would make sense to combine some of the repos as Krzysztof suggested.

As mentioned by several people I don't think this is one or the other vote. I see no problem someone setting up a subtree based repo if that helps, but I am also pro combining some of the repositories. Looking back now we can definitely say that we did split the repos apart a little too much.

--

You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.

To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

--
Jono

[hammett]

I think the underlying problem is how to streamline the experience for
us and users. I have no experience with submodules or subtrees, so
thanks for the info on that. If combining *some* of the repositories
is enough for delivering a better experience, let's go with that.

--
Cheers,
hammett
http://hammett.castleproject.org/

[Jonathon Rossi]

Thanks

My opinion now is that we should cancel this poll and start a thread talking about release cycles of the projects to determine if Krzysztof/John's suggestions are appropriate.

I agree with others that to streamline the committer and user experience will be to combine projects that we will always ship together because they belong together. In this area, focusing on our 4 main projects like ours docs have seems to be consensus, however we may have to work outwards from that if there are a few that shouldn't ship as part of a larger project.

We might also like to set up a TeamCity build that pulls from the masters to provide us a large build to more easily test for regressions and intentional breaking changes.

I guess after all that, I'm a +1 for #2 :)

[hammett]

Since the conversation stalled, I'll go ahead and merge the
subprojects this weekend. Will leave the creation of a master repos
for later.

[Craig Neuwirt]

Can you merge Castle.Components.Binder with Castle.Core instead of Castle.Monorail?

[Hamilton Verissimo de Oliveira]

Yup. Which project depends on it, besides MR?

Sent from my Windows Phone From: Craig Neuwirt
Sent: Friday, July 01, 2011 4:50 AM
To: castle-pro...@googlegroups.com

Subject: Re: [Vote] Submodules vs Aggregation of some repositories

[Craig Neuwirt]

I don't believe any other Castle projects depend on it, but I have a few projects that use it. e.g. I use it in my ASP.NET MVC stuff in conjunction with DictionaryAdapter to do my data-binding to interface models. Since DA lives in core already, it would make sense to keep the happy family together.

thanks