Mailing List Archive

On Apr 9, 2009, at 9:26 AM, Marshall Roch wrote:

> This is a concrete example of what David was saying about git
> helping to maintain custom patches. Since scriptaculous is on
> GitHub, we can fork it and commit our patches directly to our fork.
> Pulling updates from the canonical repo is just point-and-click in
> the GitHub interface. Then we can include our scriptaculous repo in
> the main Bricolage repo as a submodule.

So the question is, should I create a separate "Bricolage" account on
GitHub for stuff like this, or just put it in my own repo? Thoughts?

Best,

David

--
David Wheeler
President, Kineticode, Inc.
http://www.kineticode.com/
Kineticode. Setting knowledge in motion.[sm]

On Apr 9, 2009, at 12:32 PM, David E. Wheeler wrote:

> On Apr 9, 2009, at 9:26 AM, Marshall Roch wrote:
>
>> This is a concrete example of what David was saying about git
>> helping to maintain custom patches. Since scriptaculous is on
>> GitHub, we can fork it and commit our patches directly to our fork.
>> Pulling updates from the canonical repo is just point-and-click in
>> the GitHub interface. Then we can include our scriptaculous repo in
>> the main Bricolage repo as a submodule.
>
> So the question is, should I create a separate "Bricolage" account
> on GitHub for stuff like this, or just put it in my own repo?
> Thoughts?

A separate account, definitely. People shouldn't have to wonder which
account is the best or "official" one. It'll also make it much easier
for packagers to script things if the clone URL is standardized.

--
Marshall

On Apr 9, 2009, at 10:15 AM, Marshall Roch wrote:

> A separate account, definitely. People shouldn't have to wonder
> which account is the best or "official" one. It'll also make it much
> easier for packagers to script things if the clone URL is
> standardized.

Okay, it looks like someone used the name "bricolage" but cancelled or
something, so I've asked GitHub support go give us the account. I'll
use git@bricolage.cc as the email address for the account, so that it
stays general-ish.

I've also been doing some testing, and it looks like I'll be able to
get the entire history of Bricolage into Git without too much
difficulty (it'll just take several hours). I'll also create
repositories for some of our subprojects, such as the CPAN bundles and
bricolage.cc templates. I dunno if I'll import bricolage2 or design-
docs, though, as those projects are effectively dead. Some of the docs
might be useful for reference going forward, but I don't see any other
advantage to them. Thoughts?

So, who wants to see what it will take to get us on Lighthouse? Can we
migrate the Bugzilla data?

Best,

David

On Apr 9, 2009, at 8:05 PM, David E. Wheeler wrote:

> I'll also create repositories for some of our subprojects, such as
> the CPAN bundles and bricolage.cc templates.

I haven't seen anything out there about whether it's a good idea to
fork all of the projects you're using (like scriptaculous) even if you
don't have local changes to add, but I suspect it might be. If someone
deletes the repo you're using, it's gone. If you forked it first, your
copy survives.

> I dunno if I'll import bricolage2 or design-docs, though, as those
> projects are effectively dead. Some of the docs might be useful for
> reference going forward, but I don't see any other advantage to
> them. Thoughts?

Could maybe move that stuff to the GitHub wiki?

--
Marshall

On 10-Apr-09, at 1:29 AM, Marshall Roch wrote:

>> I dunno if I'll import bricolage2 or design-docs, though, as those
>> projects are effectively dead. Some of the docs might be useful for
>> reference going forward, but I don't see any other advantage to
>> them. Thoughts?
>
> Could maybe move that stuff to the GitHub wiki?

I'm up for moving the existing Bricolage wiki to the GitHub wiki.
Skimming through http://svn.bricolage.cc/bricolage2/trunk/ and http://svn.bricolage.cc/design-docs/
... I'd say there's A) no harm in importing them _somewhere_ and B)
probably no good reason to have them cluttering up the GitHub wiki.

Two cents,

Phillip.

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

On Apr 9, 2009, at 9:42 PM, Phillip Smith wrote:

> I'm up for moving the existing Bricolage wiki to the GitHub wiki.
> Skimming throughhttp://svn.bricolage.cc/bricolage2/trunk/ and http://svn.bricolage.cc/design-docs/
> ... I'd say there's A) no harm in importing them _somewhere_ and B)
> probably no good reason to have them cluttering up the GitHub wiki.

So where then?

Best,

David

On Apr 9, 2009, at 9:29 PM, Marshall Roch wrote:

> On Apr 9, 2009, at 8:05 PM, David E. Wheeler wrote:
>
>> I'll also create repositories for some of our subprojects, such as
>> the CPAN bundles and bricolage.cc templates.
>
> I haven't seen anything out there about whether it's a good idea to
> fork all of the projects you're using (like scriptaculous) even if
> you don't have local changes to add, but I suspect it might be. If
> someone deletes the repo you're using, it's gone. If you forked it
> first, your copy survives.

I don't expect to fork other projects unless it's useful for us, as
with your example of Scriptaculous. I was here more just talking about
Bundle::Bricolage and the like.

Best,

David

On 10-Apr-09, at 2:50 AM, David E. Wheeler wrote:

>> I'm up for moving the existing Bricolage wiki to the GitHub wiki.
>> Skimming throughhttp://svn.bricolage.cc/bricolage2/trunk/ and http://svn.bricolage.cc/design-docs/
>> ... I'd say there's A) no harm in importing them _somewhere_ and
>> B) probably no good reason to have them cluttering up the GitHub
>> wiki.
>
> So where then?

Any downside to just leaving them in the repository? I'm also fine
with moving them into the wiki too, if that's the easiest thing to do.

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

On Apr 19, 2009, at 7:40 AM, Phillip Smith wrote:

>>> I'm up for moving the existing Bricolage wiki to the GitHub wiki.
>>> Skimming throughhttp://svn.bricolage.cc/bricolage2/trunk/ and http://svn.bricolage.cc/design-docs/
>>> ... I'd say there's A) no harm in importing them _somewhere_ and
>>> B) probably no good reason to have them cluttering up the GitHub
>>> wiki.
>>
>> So where then?
>
> Any downside to just leaving them in the repository? I'm also fine
> with moving them into the wiki too, if that's the easiest thing to do.

Yeah, if perl.org is cool with keeping the SVN repo around, that will
be fine with me. The old SourceForge CVS repository has already saved
our ass in migrating to Git; best if we can keep the SVN repo around,
too. I'll likely ask them to make it read-only once I'm doing moving
things around, (hopefully this week). It has been more work that I
expected; watch [here] for deets.

http://justatheory.com/computers/vcs/git/

Best,

David

On 20-Apr-09, at 2:00 AM, David E. Wheeler wrote:

> On Apr 19, 2009, at 7:40 AM, Phillip Smith wrote:
>
>>>> I'm up for moving the existing Bricolage wiki to the GitHub wiki.
>>>> Skimming throughhttp://svn.bricolage.cc/bricolage2/trunk/ and http://svn.bricolage.cc/design-docs/
>>>> ... I'd say there's A) no harm in importing them _somewhere_ and
>>>> B) probably no good reason to have them cluttering up the GitHub
>>>> wiki.
>>>
>>> So where then?
>>
>> Any downside to just leaving them in the repository? I'm also fine
>> with moving them into the wiki too, if that's the easiest thing to
>> do.
>
> Yeah, if perl.org is cool with keeping the SVN repo around, that
> will be fine with me. The old SourceForge CVS repository has already
> saved our ass in migrating to Git; best if we can keep the SVN repo
> around, too. I'll likely ask them to make it read-only once I'm
> doing moving things around, (hopefully this week). It has been more
> work that I expected; watch [here] for deets.

Sounds like a plan.


--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com