Call for Patches: Getting Enso to Compile

[shu.chen]

To all that have worked on or gotten Enso to compile and run on
Windows and OSX, please submit a patch (preferably against the current
community branch: lp:enso/community-enso #138). You may have linked
to a personal repo somewhere, but please refresh our memories. It
would be nicest if you'd supply the patch against that version, but if
you are too busy just point us in the right place and hopefully
someone (or me) will take on that task.

~Shu

[Timothy Biron]

With Bazaar being a DVCS, I think it would be best for patches to be linked to the project in Launchpad as one of the developers personal branches which is based off of the branch Shu cited.  This should make each branch represent one patch and each branch *should* represent a working version of Enso that has only one less bug in it or only one new feature depending on what the patch did.  This will allow the greatest flexibility in terms of merging in selected fixes and/or features into the main development branch come release time.  This will also make it easier for code reviewers to focus on one feature/fix.  Fixes and features should get mergered faster if the code reviewer only needs to verify and review the code for one fix or feature rather than multiple if more than one feature and/or fix were submitted for mergering in a single branch.  Thoughts?

[Shu Zong Chen]

Thanks for the input Tim, though because I've just started to get into bzr I'm unqualified to make any solid comment about your suggestion.  Even after finishing the user-docs, I won't have the practical experience of doing group collaboration with bzr in the manner you describe nor in any other manner.  I hope those of you with experience can enlighten the rest of us.

Though, from what I can make of it, your idea  would work in our open system since everyone has write access and could make a branch.  That also solves the issue of 'how/where/in-what-form do we accept patches' (afaik, googlegroups doesn't allow file attachments, and I haven't looked into the issue tracker at launchpad yet).  I do worry that the repo would get clogged with a mess of branches assuming a lot of patches come in.  But that might be naivete on my part.

In any case, I'd like to hear more discussion and get input from real-world users of launchpad, bzr, dcvs.  However, in an effort to keep threads relevant and easy to find (unlike how community enso was discussed, decided, and launched in 'alt-tab, window switch'), let's keep this thread for submission related questions and announcements and discuss this somewhere else.

On Feb 3, 2009 4:51 PM, "Timothy Biron" <timoth...@gmail.com> wrote:

With Bazaar being a DVCS, I think it would be best for patches to be linked to the project in Launchpad as one of the developers personal branches which is based off of the branch Shu cited.  This should make each branch represent one patch and each branch *should* represent a working version of Enso that has only one less bug in it or only one new feature depending on what the patch did.  This will allow the greatest flexibility in terms of merging in selected fixes and/or features into the main development branch come release time.  This will also make it easier for code reviewers to focus on one feature/fix.  Fixes and features should get mergered faster if the code reviewer only needs to verify and review the code for one fix or feature rather than multiple if more than one feature and/or fix were submitted for mergering in a single branch.  Thoughts?

On Tue, Feb 3, 2009 at 6:23 PM, shu.chen <sirp...@gmail.com> wrote: > > > To all that have worked...

[shu.chen]

Blackdaemon had posted a link to a private git repo a few months back
with fixes getting the win build to install. The no-ip.org address
doesn't direct to anything currently. If anyone grabbed a copy of
that, please post it somewhere or contact me and I'll scrounge up a
place to drop it.

~shu

[Timothy Biron]

Didn't he post diffs for the patch in another thread as well?  I'll search around sometime this week to see if he did.

[shu.chen]

No need to search - he did post a diff, but also hosted on his own
server. I tried a little google-stalking to see if he relocated or
changed to a different no-ip service, but with no luck. I did send a
message to him directly through groups' "reply to author" function. I
don't see a record of it here or in my gmail, so I'm not sure if the
message got through.

~shu

[ivancho]

I pulled the zip file from Blackdaemon back then - right now you can
grab it from
http://dl.getdropbox.com/u/184592/enso/enso-win32-experimental-081006.zip

but I would prefer if we find a better home for it.

[blackdaemon]

Hi guys,

I am very happy seeing this activity assembling around open-source
Enso.
I was quite busy with my personal life recently, moving to new home
and
so my server machine is still sitting in the pile of things waiting to
be
processed ;-)

I will try to get the machine up and running this week so my git repo
can be
accessed again. Or isn't that actual anymore? Sorry, I had no time to
read
all messages of this group yet.

Looking forward to participate again.

On Feb 9, 8:03 pm, "shu.chen" <sirpe...@gmail.com> wrote:
> No need to search - he did post a diff, but also hosted on his own
> server.  I tried a little google-stalking to see if he relocated or
> changed to a different no-ip service, but with no luck.  I did send a
> message to him directly through groups' "reply to author" function.  I
> don't see a record of it here or in my gmail, so I'm not sure if the
> message got through.
>
> ~shu
>
> On Feb 9, 8:41 am, Timothy Biron <timothybi...@gmail.com> wrote:
>
>
>
> > Didn't he post diffs for the patch in another thread as well?  I'll search
> > around sometime this week to see if he did.
>
> > On Mon, Feb 9, 2009 at 1:24 PM, shu.chen <sirpe...@gmail.com> wrote:
>

> > >Blackdaemonhad posted a link to a private git repo a few months back

> > > with fixes getting the win build to install.  The no-ip.org address
> > > doesn't direct to anything currently.  If anyone grabbed a copy of
> > > that, please post it somewhere or contact me and I'll scrounge up a
> > > place to drop it.
>

> > > ~shu- Hide quoted text -
>
> - Show quoted text -

[Shu Zong Chen]

@blackdaemon:
The inquiries for your git repo were so we could incorporate your changes to our new trunk at LP.  You had posted a zip of your repo and someone in the group kept a copy of it, so we don't really need the git access anymore.  I still haven't got around to looking at your changes, but since you're back it would probably be best if you did so.  However, if you're still busy with moving and life let me know and I'll take care of it.
Our first goal here is to have the codebase in a form where it'll compile and work.  I noticed you've joined the LP team so I won't bother to link you to the relavant pages to get incorporated - glad to see you've returned and look forward to your contributions!

~shu

[blackdaemon]

@shu:

I pushed branch rev139 with win32 patches:
lp:~blackdaemon/enso/win32build

~bd

On Feb 19, 2:14 am, Shu Zong Chen <sirpe...@gmail.com> wrote:
> @blackdaemon:
> The inquiries for your git repo were so we could incorporate your changes to
> our new trunk at LP. You had posted a zip of your repo and someone in the
> group kept a copy of it, so we don't really need the git access anymore. I
> still haven't got around to looking at your changes, but since you're back
> it would probably be best if you did so. However, if you're still busy with
> moving and life let me know and I'll take care of it.
> Our first goal here is to have the codebase in a form where it'll compile
> and work. I noticed you've joined the LP team so I won't bother to link you
> to the relavant pages to get incorporated - glad to see you've returned and
> look forward to your contributions!
>
> ~shu
>

[shu.chen]

From what I've briefly looked over, everything seems fine. I can also
confirm that the changes don't break anything in Kubuntu 8.10. I'll
test out the windows binaries on my Win32 systems in a bit. How
should we handle submission review? We don't exactly have an
automated test suite built up, and I'm not certain the best way to do
this in LP. I have a list of testers from the "call for volunteers"
thread - should I add them individually as "reviewers" for the merge
proposal, or is there a simpler way? If I make a subgroup (e.g. Enso
Testers) and assign that team to review do they all individually need
to approve?

[Stuart Langridge]

> From what I've briefly looked over, everything seems fine. I can also
> confirm that the changes don't break anything in Kubuntu 8.10. I'll
> test out the windows binaries on my Win32 systems in a bit. How
> should we handle submission review? We don't exactly have an
> automated test suite built up, and I'm not certain the best way to do
> this in LP. I have a list of testers from the "call for volunteers"
> thread - should I add them individually as "reviewers" for the merge
> proposal, or is there a simpler way? If I make a subgroup (e.g. Enso
> Testers) and assign that team to review do they all individually need
> to approve?

OK, Shu and I chatted about this a bit. I suggest the following:

1. You want to submit a patch to Enso. First, branch the Enso codebase:
bzr branch lp:enso/community-enso name-for-your-branch

2. Make the changes in your branch until you're happy with them
(make some changes)
bzr commit -m "comment about the change you're committing)
(repeat)

3. Push your branch to launchpad:
bzr push lp:~YOUR_LAUNCHPAD_ID/enso/name-for-your-branch

4. Propose the branch for merging; go to your branch's page in
Launchpad and say "propose for merging into another branch". Propose
it for merging into ~communityenso/enso/community-enso (NOT
~vcs-imports/enso/trunk) and add a comment explaining what your branch
does

5. Your branch will now get reviewed. You should wait until the
platform leads have reviewed it for each platform to confirm that it
doesn't break any platform: platform leads are me/Shu for Linux,
blackdaemon for Windows, someone for Mac OS X

6. If it gets "needs review", fix the problems and post a comment
saying you've done so: repeat steps 5 and 6 until your branch is
approved by everyone

7. Merge your branch into trunk and commit trunk:
bzr branch lp:enso/community-enso
cd community-enso
bzr merge lp:~YOUR_LAUNCHPAD_ID/enso/name-for-your-branch
bzr commit -m "merge name-for-your-branch into trunk"
bzr push

(if you already have the community-enso branch, just "bzr pull" inside it)

And you are done.

A thought about branching:
Once a branch has been merged, I prefer (personally) that extra
changes are not made to it; instead, create a new branch. (So don't
have one "win32changes" branch which keeps getting changed and merged;
instead, create a new branch every time you want to make a change.
Branches are cheap.)

Does this seem like a good scheme? If people like this, I'll write it
up on the wiki and then we should adopt it.

sil

[Timothy Biron]

I think this process works out.  It is almost exactly like what I proposed in the other thread but a little simpler and included exact commands for merging/branching/etc.