On Thu, Aug 05, 2010 at 10:34:43AM +0200, Peter Soetens wrote:
> On Wednesday 04 August 2010 10:20:35 Sylvain Joyeux wrote:
> > On 08/03/2010 11:00 PM, Markus Klotzbuecher wrote:
> > > On Tue, Aug 03, 2010 at 03:32:19PM +0200, Peter Soetens wrote:
> > >> My rtt-2.0-mainline on github has diverged from the 'master' branch on
> > >> gitorious because of a patch of Sylvain. I'll resolve this by using a
> > >> merge, but I propose that we only use the project's repository for
> > >> merging merge requests and that we push our commits on our own clones.
> > >> Or maybe not, but we need some policy.
> > >>
> > >> Also, we don't get email notifications of merge requests. For example,
> > >> the merge request of sylvain can only be commented on the website. Also,
> > >> a 'make check' of his branch hangs in testFileDescriptorActivity[1]. I
> > >> don't see how I can reject it, except by leaving a comment or closing
> > >> it.
> > >>
> > >> It's no way of working actually. Gitorious merging is quite basic and
> > >> fully manual. Maybe I'd be more comfortable with Gerrit (
> > >> http://gerrit.googlecode.com/svn/documentation/2.1.4/index.html ). We
> > >> could set this up on the Hudson server after the 2.0 release.
> > >
> > > Heres my 2 C: I havn't had time to give gitourious a fair chance yet,
> > > but from previous experience I know that I tend not to stick with
> > > anything which happens outside of my inbox (or git repo).
> > >
> > > Therefore it is IMO a must that merge request are sent to the list.
> >
> > I don't know why Peter (or you for that matter) do not get the email
> > notifications. I know I get them (including peter replies to my replies)
> > and I am *not* the owner of anything anymore (orocos-maintainer is).
> > Peter: you should probably send a support request to the gitorious website.
>
> I'm doing so. I wonder, Markus, did you get any messages from gitorious ? Is

No, nothing besides the initial "added to project" mail.

Markus

On 08/05/2010 10:34 AM, Peter Soetens wrote:
> On Wednesday 04 August 2010 10:20:35 Sylvain Joyeux wrote:
>
>> On 08/03/2010 11:00 PM, Markus Klotzbuecher wrote:
>>
>>> On Tue, Aug 03, 2010 at 03:32:19PM +0200, Peter Soetens wrote:
>>>
>>>> My rtt-2.0-mainline on github has diverged from the 'master' branch on
>>>> gitorious because of a patch of Sylvain. I'll resolve this by using a
>>>> merge, but I propose that we only use the project's repository for
>>>> merging merge requests and that we push our commits on our own clones.
>>>> Or maybe not, but we need some policy.
>>>>
>>>> Also, we don't get email notifications of merge requests. For example,
>>>> the merge request of sylvain can only be commented on the website. Also,
>>>> a 'make check' of his branch hangs in testFileDescriptorActivity[1]. I
>>>> don't see how I can reject it, except by leaving a comment or closing
>>>> it.
>>>>
>>>> It's no way of working actually. Gitorious merging is quite basic and
>>>> fully manual. Maybe I'd be more comfortable with Gerrit (
>>>> http://gerrit.googlecode.com/svn/documentation/2.1.4/index.html ). We
>>>> could set this up on the Hudson server after the 2.0 release.
>>>>
>>> Heres my 2 C: I havn't had time to give gitourious a fair chance yet,
>>> but from previous experience I know that I tend not to stick with
>>> anything which happens outside of my inbox (or git repo).
>>>
>>> Therefore it is IMO a must that merge request are sent to the list.
>>>
>> I don't know why Peter (or you for that matter) do not get the email
>> notifications. I know I get them (including peter replies to my replies)
>> and I am *not* the owner of anything anymore (orocos-maintainer is).
>> Peter: you should probably send a support request to the gitorious website.
>>
> I'm doing so. I wonder, Markus, did you get any messages from gitorious ? Is
> Sylvain the ony one receiving mails because he created the project ??? Could
> someone send me a message on gitorious to see if I get that ?
>
>
>>
>>> What I personally like best is that small amounts of patches are sent
>>> directly to the list (using git format-patch) and for larger sets use
>>> "git-request-pull". A [PATCH] tag in the subject lets people filter
>>> out patches, but hey who would do that on a developers ML?
>>>
>> As for the "sending patches to the list", as Steven would have put it,
>> it's a "people have different ways to do stuff". I had to use the
>> send-patches-to-list-and-review-and-resend-and-so-on workflow when I
>> tried to get patches through to git itself. Let's be clear about this:
>> if it is the chosen way for RTT *I will not send any patches to RTT
>> anymore*. I will develop on my fork of RTT and it will be up to you to
>> get the patches integrated. I hated having my mailbox full of useless
>> mails, hated having to read non-syntax-colorized code in email, hated to
>> have to browse through the patches to see what people had to say about
>> it and hated how the whole git-am/git-email worked.
>>
>> In other words: I came to hate the whole workflow.
>>
> I'm also wondering often how people manage through the pile of patches on some
> mailing lists. An email reader is not an IDE and most of them screw up patches
> anyway. I am inclined to follow Markus' reasoning: small things *can* go
> through the mailing lists, it draws immediate attention and its manageable.
> Big things go through a managed pull request interface. The orocos-dev
> mailinglist *must* receive such requests such that everyone has a chance to
> look and comment, and ideally every comment on that ends up on the ML as well,
> just like Bugzilla works.
>
> If you choose to send only pull requests, that's fine for me, I'll always look
> at them and merge asap. However, be aware that the current delay is only there
> because:
> 1) I nor the list gets any notifications
> 2) The one that I noticed (by visiting gitorious) failed a unit test, so I had
> to wait until you fixed it.
> 3) I was out of office yesterday, give me a break.
>
Fair enough. I felt impatient and should not have put that on you. Sorry.

Now, it appears that the mandatory review process is incompatible with
our (DFKI) needs. I will definitely have to dup the whole
orocos-toolchain repositories, have us track the clones and and develop
on them (and every once in a while push the changes to the main repos).
Why ? Because we often can't wait three days for simple patches to go
through.

Complex stuff often need more testing anyway, so it is fine if it takes
one or two weeks to be propagated to the main repos. Simple bugfixes
usually fix a problem we have *here* and *now* and must therefore be
propagated, well, here and now.
--

Sylvain Joyeux
Space& Security Robotics

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
Fax: +49 (0)421 218-64150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

On 08/04/2010 01:31 PM, Markus Klotzbuecher wrote:
> On Wed, Aug 04, 2010 at 10:20:35AM +0200, Sylvain Joyeux wrote:
>
>> On 08/03/2010 11:00 PM, Markus Klotzbuecher wrote:
>>
>>> On Tue, Aug 03, 2010 at 03:32:19PM +0200, Peter Soetens wrote:
>>>
>>>
>>>> My rtt-2.0-mainline on github has diverged from the 'master' branch on
>>>> gitorious because of a patch of Sylvain. I'll resolve this by using a merge,
>>>> but I propose that we only use the project's repository for merging merge
>>>> requests and that we push our commits on our own clones. Or maybe not, but we
>>>> need some policy.
>>>>
>>>> Also, we don't get email notifications of merge requests. For example, the
>>>> merge request of sylvain can only be commented on the website. Also, a 'make
>>>> check' of his branch hangs in testFileDescriptorActivity[1]. I don't see how I
>>>> can reject it, except by leaving a comment or closing it.
>>>>
>>>> It's no way of working actually. Gitorious merging is quite basic and fully
>>>> manual. Maybe I'd be more comfortable with Gerrit (
>>>> http://gerrit.googlecode.com/svn/documentation/2.1.4/index.html ). We could
>>>> set this up on the Hudson server after the 2.0 release.
>>>>
>>>>
>>> Heres my 2 C: I havn't had time to give gitourious a fair chance yet,
>>> but from previous experience I know that I tend not to stick with
>>> anything which happens outside of my inbox (or git repo).
>>>
>>> Therefore it is IMO a must that merge request are sent to the list.
>>>
>>>
>> I don't know why Peter (or you for that matter) do not get the email
>> notifications. I know I get them (including peter replies to my replies)
>> and I am *not* the owner of anything anymore (orocos-maintainer is).
>> Peter: you should probably send a support request to the gitorious website.
>>
>>
>>> What I personally like best is that small amounts of patches are sent
>>> directly to the list (using git format-patch) and for larger sets use
>>> "git-request-pull". A [PATCH] tag in the subject lets people filter
>>> out patches, but hey who would do that on a developers ML?
>>>
>>>
>> As for the "sending patches to the list", as Steven would have put it,
>> it's a "people have different ways to do stuff". I had to use the
>> send-patches-to-list-and-review-and-resend-and-so-on workflow when I
>> tried to get patches through to git itself. Let's be clear about this:
>> if it is the chosen way for RTT *I will not send any patches to RTT
>> anymore*. I will develop on my fork of RTT and it will be up to you to
>> get the patches integrated. I hated having my mailbox full of useless
>> mails, hated having to read non-syntax-colorized code in email, hated to
>> have to browse through the patches to see what people had to say about
>> it and hated how the whole git-am/git-email worked.
>>
>> In other words: I came to hate the whole workflow.
>>
> Fair enough! So that's why we must be able to allow different
> workflows.
>
In principle, I agree. Now, I personally want to promote use and (more
importantly) promote contributions.

So, we will need to find a (i) public, (ii) well done, (iii) well known
[ideally, people should be likely to already have an account there],
(iii) not maintained by us [I don't think we have the manpower for that]
website that provides all the different workflows ...

On Tue, Aug 3, 2010 at 5:29 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On 08/03/2010 05:08 PM, Peter Soetens wrote:
>>
>> On Tuesday 03 August 2010 15:53:39 Sylvain Joyeux wrote:
>>
>>>
>>> On 08/03/2010 03:32 PM, Peter Soetens wrote:
>>>
>>>>
>>>> My rtt-2.0-mainline on github has diverged from the 'master' branch on
>>>> gitorious because of a patch of Sylvain. I'll resolve this by using a
>>>> merge, but I propose that we only use the project's repository for
>>>> merging merge requests and that we push our commits on our own clones.
>>>> Or
>>>> maybe not, but we need some policy.
>>>>
>>>> Also, we don't get email notifications of merge requests. For example,
>>>> the merge request of sylvain can only be commented on the website. Also,
>>>> a 'make check' of his branch hangs in testFileDescriptorActivity[1]. I
>>>> don't see how I can reject it, except by leaving a comment or closing
>>>> it.
>>>>
>>>
>>>   * weird, I do get email notifications.
>>>
>>
>> Probably because you are the owner of the project ? For some reason, not
>> the
>> whole team receives these. I have 'Send email notifications' on, there's
>> nothing in my spam folder. Maybe 'orocos-dev' should become the owner of
>> the
>> gitorious project ? I didn't receive an email when you replied to my
>> comments.
>>
>
> Look at the "You're watching" list on your dashboard ... If it contains

It contains all these things, I just don't get the emails. The only
mails I got were account activation, and being added as a team member.

>>
>>
>>>
>>>   * true, you can only comment on gitorious itself. But for me it is a
>>> feature as comments are directly on the diffs (which I like very much)
>>>
>>
>> Just like in email :-)
>>
>
> I prefer the nice colorized, formatted version of gitorious, but YMMV.
>
> Especially for multi-commit merges.

I prefer email notifications in combination with a web frontend, just
like the Bugzilla does. That really works.

>
>>>   * the purpose of merge requests is that they should be updated by the
>>> requesters, based on the people comments, until it can be merged in. To
>>> update, you only have to push your new changes to the
>>> refs/merge-requests/<request-id>  (i.e. in my case /1). I find it a very
>>> nice way to integrate the review process.
>>>   * finally, merges should ALWAYS remain manual. Someone does the merge,
>>> he's happy, he pushes to master.
>>>
>>
>> I understand.
>>>>
>>>> It's no way of working actually. Gitorious merging is quite basic and
>>>> fully manual.  Maybe I'd be more comfortable with Gerrit (
>>>> http://gerrit.googlecode.com/svn/documentation/2.1.4/index.html ). We
>>>> could set this up on the Hudson server after the 2.0 release.
>>>>
>>>
>>> The whole point of using gitorious/github is to promote contributions.
>>> Using our own git servers is definitely *not* doing that. And when I
>>> looked at gerrit, I was really not happy as I felt it was really getting
>>> too much in the way.
>>>
>>
>> That was also my first impression. But I don't say ditch gitorious or a
>> public
>> hosted repos. You can use Gerrit purely for the review process and use the
>> repositories at github or gitorious for the code. The only change is that
>> the
>> merge on master is not done by you or me, but by Gerrit, after review
>> ('looks
>> good') after verification (merges and passes unit tests). It's just
>> pushing to
>> another git URL (refs/for/master), then have the web interface review,
>> then
>> merge by Gerrit. We already have experience with hudson, hudson can be
>> triggered by updates on git repos, so I think its feasible.
>>
>
> I personally think that a mandatory review process is not feasible given how
> many developpers we are. Honestly, for instance, I will probably not look at
> the merge request you sent, because reviewing it will require that I get
> into code that I don't know right now.

The review would require flagging it as 'looks good'. Not exploring
alternative designs or other time consuming efforts. Maybe you spot a
memleak easily or a possible exception.

>
> The way I think of it, merge requests should be for non-members to send
> patches that would get reviewed by the guy(s) that is(are) the most
> knowledgeable in that part of the toolchain (i.e. orogen => me, rtt => peter
> and so on). For members, they can be used when it really makes sense, but
> definitely not be "mandatory".
>
> Honestly, you have developped everything on github without asking anyone
> about anything (this sentence is not intended as a critic in any way). Now,
> you want each and every one of your commits to be reviewed ?

Didn't that suck ?

I profoundly believe that reviews would help the quality and the
velocity of coding and also to share some ownership. The only thing
that got me somewhat straight in all these months were talks with
Markus (sanity checks) and the unit tests (functional checks). We have
a pretty open development process, but I want it to be even more open.
I'd like to structure the changes in 'merge requests' and these need
to be announced, such that discussion takes place before it's too
late.

I don't mind reviewing changes for orogen/typelib etc. given that they
are presented in a coherent way. I think the other stakeholders in
rtt/ocl etc think alike for that part. Also, a review delay doesn't
hold *you* back, it only delays the mainline. In case of 'emergencies'
there is a push url that bypasses the review directly.

Don't waste too much breath on this yet, it's post a 2.0 thing.

Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev