2014-05-28 14:43 GMT+02:00 Nicolas Cellier < [email protected]>:
> > > > 2014-05-28 10:26 GMT+02:00 Norbert Hartl <[email protected]>: > > >> Am 28.05.2014 um 10:08 schrieb kilon alios <[email protected]>: >> >> 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 <[email protected]>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 <[email protected]> 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 <[email protected]>wrote: >>> >>>> >>>> On 28 May 2014, at 09:20, Norbert Hartl <[email protected]> wrote: >>>> >>>> > >>>> > >>>> >> Am 28.05.2014 um 08:47 schrieb Marcus Denker <[email protected] >>>> >: >>>> >> >>>> >> >>>> >>> On 28 May 2014, at 03:17, Gabriel Cotelli <[email protected]> >>>> 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 >>>> >>> >>> >>> >> >> >
