2014-05-28 14:43 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2014-05-28 10:26 GMT+02:00 Norbert Hartl <norbert@hartl.name>:
Am 28.05.2014 um 10:08 schrieb kilon alios <kilon.alios@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@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@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@me.com>wrote:
On 28 May 2014, at 09:20, Norbert Hartl <norbert@hartl.name> wrote:
Am 28.05.2014 um 08:47 schrieb Marcus Denker <marcus.denker@inria.fr :
On 28 May 2014, at 03:17, Gabriel Cotelli <g.cotelli@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