[Pharo-dev] MetaRepoForPharo40

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed May 28 08:47:56 EDT 2014


2014-05-28 14:43 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

>
>
>
> 2014-05-28 10:26 GMT+02:00 Norbert Hartl <norbert at hartl.name>:
>
>
>> Am 28.05.2014 um 10:08 schrieb kilon alios <kilon.alios at gmail.com>:
>>
>> Well I am a big fan of github and git myself. Though I also love
>> smalltalkhub , so far I had no serious issues with it apart from the site
>> going down at times and not being able to browser new projects.
>>
>> The thing with public access is that you don't worry about it unless a
>> problem occurs. Which saves time and is less demanding on the maintenance
>> side. I will have to agree that github repo with pull requests would be
>> ideal. None the less , things look that are moving towards a better
>> direction :)
>>
>> You can have public access in each individual project. I’m just saying
>> that the configuration of a project is only copied to _the_ pharo software
>> catalog if it isn’t broken. So while everyone has public access to a
>> project and there is an automatic build on a CI the configuration will be
>> arrive in the meta repo sooner or later. No one has to do anything.
>> If public access would the best way to go pull requests wouldn’t be so
>> prominent. It is a solution to let people easily participate without having
>> access to a repository.
>>
>> Norbert
>>
>>
> If it's dynamic, we could also trace which particular change in the Kernel
> is causing a regression in a package, and that would be a GOOD thing.
>
>
I mean GOOD both for kernel developers (knowing how many packages you broke
with a single API change might introduce some stiffness/damping in the
change for changing policy) and package developpers (this can help
localizing exactly which API was deprecated/changed)


> But do we still want to have a right to temporarily break things in the
> kernel image, or should we tend to a continuous integration? In the former
> case, the pace of 2.0->3.0 change rate might generate a lot of noise ;)
>
>
>> You just remind me to give gitfiletree another try.
>>
>>
>> On Wed, May 28, 2014 at 10:56 AM, Yuriy Tymchuk <yuriy.tymchuk at me.com>wrote:
>>
>>> There haven’t as far as I know. But "I trust everyone. It's the devil
>>> inside them I don't trust”. I really like the workflow that emerged from
>>> git and github. If one wants to contribute, he forks project, makes changes
>>> and submits a pull request. Then you analyse changes made and either merge
>>> them into the project, or not (also pull request can be priorly checked by
>>> CI and so on). Now if you have have something completely “open” it means
>>> that you trust all the world, and I would say that it’s not a good thing to
>>> do. Yes, inbox is not Pharo repository. But still.
>>>
>>> Uko
>>>
>>>
>>> On 28 May 2014, at 09:37, kilon alios <kilon.alios at gmail.com> wrote:
>>>
>>> I dont see a big problem not having MetaRepoForPharo4 as public access ,
>>> its not as if anyone will plant a pharo virus anytime soon and if a mistake
>>> is done, its not the end of the world , people can fix it if they find so
>>> annoying. Have there been any major issues so far with public access ?
>>>
>>>
>>> On Wed, May 28, 2014 at 10:28 AM, Yuriy Tymchuk <yuriy.tymchuk at me.com>wrote:
>>>
>>>>
>>>> On 28 May 2014, at 09:20, Norbert Hartl <norbert at hartl.name> wrote:
>>>>
>>>> >
>>>> >
>>>> >> Am 28.05.2014 um 08:47 schrieb Marcus Denker <marcus.denker at inria.fr
>>>> >:
>>>> >>
>>>> >>
>>>> >>> On 28 May 2014, at 03:17, Gabriel Cotelli <g.cotelli at gmail.com>
>>>> wrote:
>>>> >>>
>>>> >>> Hi,
>>>> >>> is the Meta Repo for Pharo 4 ready to use?
>>>> >>>
>>>> >>> I've configured my jobs in the contribution ci server to run also
>>>> for Pharo 4. But I can't copy the configuration to the meta repo for Pharo
>>>> 4 to make it available in the Configuration Browser.
>>>> >>> Maybe some permissions are missing?
>>>> >>>
>>>> >>
>>>> >> Yes, public write access was missing… I added that for now, but of
>>>> course the question is: do we really want it to be writable by everyone?
>>>> >
>>>> > No! And I would also want only configs to be put into the meta repo
>>>> that build green. So basically only the pharo contributions CI should
>>>> upload configs. But I can see that this might be too much effort and
>>>> restriction.
>>>> >
>>>> > Norbert
>>>>
>>>> We just need a better infrastructure. Look at ATOM project. 1)
>>>> contributions are made with pull requests 2) they have a dedicated apm tool
>>>> for package submission/management. With monticello we’ve achieved the best
>>>> we can. And I guess we don’t have enough resources to build and maintain
>>>> new tools.
>>>>
>>>> Uko
>>>>
>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140528/267fac71/attachment-0002.html>


More information about the Pharo-dev mailing list