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.
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 >>> >> >> >> > >
