[Vm-dev] Changing my mailing list subscription

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Sep 5 20:05:16 UTC 2012


2012/9/5 Camillo Bruni <camillobruni at gmail.com>:
>
>
> On 2012-09-05, at 16:20, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
>>
>> On 2012-09-05, at 04:31, "David T. Lewis" <lewis at mail.msen.com> wrote:
>>
>>> Are the cog tracker emails helpful, or too much noise? As vm-dev list
>>> admin, I turned them on based on a request to do so, but if it is too
>>> much information, I'll turn it back off. The cog issue tracker is open to
>>> everyone, so there is no real need to provide an automated feed to vm-dev
>>> if it is causing too much traffic.
>>>
>>> Opinions?
>>
>>
>> I very much like code diffs sent to the mailing list to keep everyone informed what's going on. Bug tracker traffic usually is more noisy. E.g. for Etoys we have two lists - the developer list which also gets code commit diffs, and a "notify" list which gets bug tracker updates and non-code commits (translated strings mostly). As one of the Etoys "core" developers I am subscribed to both lists, of course. So here on vm-dev, if the traffic turns out to be too much, we could create a vm-notify list. But for now I'd give it a try, at least for a couple of weeks.
>>
>> It would be nice of course if the work on those tickets went back into the official VMs.
>
> what is the official vm? sorry I am rather new to that...
>
>> So far the work going on in the git repositories has been more or less invisible. I don't think I have seen patches contributed back to the master repository at squeakvm.org?
>
> I have seen not so many changes coming from the squeakvm repository, comparing
> to our repository at gitorious... so from my naïve point of view I consider
> the latter one more important.
>
> besides svn does not play along with multiple fixes / multiple people working.
> just look at github, how programmer kids today work on software today:
> unstructured, multi forked, do-what-you-want. If you have something interesting
> you propose it as a pull-request, and that works extremely well with unstructured,
> loose organizations

However, having a trunk handled with SVN and branches handled with git
is perfectly manageable right?

Nicolas


More information about the Vm-dev mailing list