Idea: move build script to a dedicated repo

[necolas]

An idea. Might be a terrible one.

Why?

• The build script is a useful project in its own right.
• A repo dedicated to the build script(s) could help bring in more contributors.
• Might be easier to update the build script across projects. Among the h5bp projects alone, we have 3 separate repos that use the build script. At the moment they all need manual updating.
• Like the server-config repo, maybe this could become a place to find one of several build scripts...whichever is suitable for your project.

How?

Not entirely sure but this could be doable using git-submodule or git-subtree, which is what solarized uses to keep all its repos synced in one master repo.

One possibility would be to have each build script in it's own repo but synced in the master 'build-scripts' repo. That way you can include any one build script in your project.

Problems

• Referencing a remote repo but also customising it to work with a project's directory structure?
• Up-front cost of moving.
• (other)

What do @mklabs, @KushalP, @roblarsen, and anyone else helping out with the build scripts or working on the project think?

[roblarsen]

I think it's a great idea, especially if it kick starts my longstanding wish to have multiple build solutions available for the project. But even if it doesn't and it's just centered around the ant script, I think it would be cool to have a focused place to tinker with it.

I've never managed git submodules through a github repo, so I don't know how much overhead there would be at that end, but as an end user they're no big deal and would do exactly what you imagine.

[ivoba]

yes, good idea since i am mainly interested in the build
on top of that one could again make some packages as bundled submodules plus some magic that would combine the plate, the build and whatever fits in there
decouple!

[mklabs]

I'm definitely +1 on this too.

It'll probably get much easier to work with build scripts. Maybe another benefit I see with that move would be to make the main repo smaller.

[paulirish]

+1

[roblarsen]

(I keep waiting for someone to burst in and object ace attorney style)

Otherwise, is this a go?

[necolas]

Looks like it. Shall we start planning out how we might organize things and how it will work in practice?

[roblarsen]

that sounds like a good next step, especially since some of the plumbing is important to get right- technically and from an ease-of-use perspective

[necolas]

These articles look relevant to what we're trying to do:

• Subtree merge
• Split a subpath into a new repo

[roblarsen]

Playing around with this a little bit today Splitting a subpath into a new repo was straightforward.

https://github.com/roblarsen/h5bp-ant-build

I started looking at the subtree merge strategy- can someone git-smarter than I am explain the benefits for both the repo owner and consumers of that over simply doing a submodule?

[necolas]

Rob, I found some handy explanation about git-subtree: https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt

How does this seem like it would compare to your experience with submodule?

[roblarsen]

Reading that, it looks like it would be even easier for end users, which is good. With submodules, end users have to actually pay attention to the fact that there are submodules.

[addyosmani]

There appears to be an overwhelming +1 on this, but I'll add one more :)

imo developers would greatly benefit from having a solid built script they can refer to as a base for projects. To date I've been pointing them to the H5BP one + wiki, but something a little less project-specific would be great.

@roblarsen do you have plans on taking another look at the work in https://github.com/roblarsen/h5bp-ant-build soon?

[roblarsen]

I've been planning on it, yeah. I've had a big-ass writing deadline that's taken up my whole month, but that's winding down this week. I'm assuming everyone is comfortable with the subtree plan? From the perspective of the new repo it's a no-brainer.

[roblarsen]

I just looked back at this previous comment and I realized I wasn't being clear. While I'm comfortable with the new repo part, I want to make sure @paulirish and the rest of the folks who maintain the main @h5bp project are comfortable with whatever solution we come up with the keep the two projects linked. I mean, we can clearly just start work on the separate repo starting Monday or whatever. That's a no-brainer. I just want to make sure everyone is comfortable with the solution we come up with to keep the two projects linked. I'm not enough of a git guru to walk through what an actual best practice here (paging a git guru)

Long story short, I'm good with moving ahead on the new repo and hopefully everyone else is good with whatever plumbing we need to do to keep everything synced.

Now... I'm going to go XMAS it up for two days.

[paulirish]

i don't think a submodule would be all that bad in this case, but i'm curious about the subtree as well.
i guess let's proceed with subtree as it seems to have a slight advantage

[necolas]

This is one of the priority issues IMO. From the sound of things, subtree would be easier for the move, for users, and for syncing various build scripts in one repo and one build script in the h5bp repo. Might be worth pinging Ethan (Solarized), who has done this before...or double checking with someone who knows their git to see if this is a good plan.

[roblarsen]

+1 on pinging a git genius.

[KushalP]

If we had a "build" sub folder similar to that of what's used for ant, we
could then designate it as a ".gitmodule". However the problem with this is
that most users wouldn't know to manually assign the build branch (for
their tool).

There could also be path issues with build tools, but I'm not sure about
that. The example I'm thinking of is that you couldn't do rake or cake
in the base dir without some monkey-patching.

[paulirish]

I'm confident enough in subtree for us to move forward on this now. :)
@roblarsen do you want to touch base with either ethan or apenwarr in order to confirm any thoughts?

[necolas]

FYI: http://help.github.com/subtree-merge/

Will be handy for managing the combined build script repo, and for pointing people to when they want to merge a build script repo into h5bp.

[roblarsen]

I'm probably as available to work on this right now as I'll ever be, so if we want to move forward with this starting... today or whatever, I'm already rolling up my sleeves.

[necolas]

That would be great. Are you happy with this solarized-like approach:

One possibility would be to have each build script in it's own repo but synced in the master 'build-scripts' repo. That way you can include any one build script in your project