So it is clear that we need configurations that will be created and
managed automatically and will enable swapping of repositories. We had
already several discussions on this theme and from my point of view we
need:
- own separate repository for every semi-external project. So
something
2016-06-09 16:32 GMT+02:00 stepharo :
> I have a mental block to contributing to part of Pharo maintained in
>> external repositories. Maybe its unreasonable, but it just *feels*
>> like too much friction. If I've worked on an issue, I. just. want.
>> to. submit. it!
>>
>
>
On Thu, Jun 9, 2016 at 3:42 PM, Pavel Krivanek wrote:
>
>
> 2016-06-08 19:40 GMT+02:00 stepharo :
>>
>> ***THANKS*** Pavel.
>>
>> Yes it is the best way to make sure that nobody wants to work at this
>> level. We discussed this problem during the last
Cargo will not fix the dependency mess.
maybe it will be easy the process, but it will not fix the real problem: we
have a system that’s not made in a modular way. We are working hard to make it
possible, but until we finish that there will be fixes that will touch more
than one “module” and
> On 09 Jun 2016, at 10:03, Denis Kudriashov wrote:
>
> So does we all agree to commit fixes for external packages by slices without
> new configs?
that would break the bootstrap process, so no.
Esteban
>
> 2016-06-09 9:42 GMT+02:00 Pavel Krivanek
On Thu, Jun 9, 2016 at 9:58 AM, Pavel Krivanek wrote:
> We cannot do that right now. I hope that we will replace configurations with
> Cargo.
When Cargo will be deployed ?
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
We cannot do that right now. I hope that we will replace configurations
with Cargo.
-- Pavel
2016-06-09 10:03 GMT+02:00 Denis Kudriashov :
> So does we all agree to commit fixes for external packages by slices
> without new configs?
>
> 2016-06-09 9:42 GMT+02:00 Pavel
So does we all agree to commit fixes for external packages by slices
without new configs?
2016-06-09 9:42 GMT+02:00 Pavel Krivanek :
>
>
> 2016-06-08 19:40 GMT+02:00 stepharo :
>
>> ***THANKS*** Pavel.
>>
>> Yes it is the best way to make sure that
2016-06-08 19:40 GMT+02:00 stepharo :
> ***THANKS*** Pavel.
>
> Yes it is the best way to make sure that nobody wants to work at this
> level. We discussed this problem during the last board meeting. This is why
> I proposed the following process.
>
> When the core Pharo
On 08/06/16 11:05, Pavel Krivanek wrote:
In ideal state you should create
new versions of the configurations
Hi Pavel, please take a look at my earlier
contributions on this subject. This is a solved
problem.
Stephan
One of the reasons that Versionner may not have been supporting
baselines is that the MetacelloToolBox support for BaselineOf was not up
to snuff.
A couple of weeks ago I added additional support for updating a
BaselineOf[1]. If additional features/support is needed from the
MetacelloToolBox
***THANKS*** Pavel.
Yes it is the best way to make sure that nobody wants to work at this
level. We discussed this problem during the last board meeting. This is
why I proposed the following process.
When the core Pharo developers are in need to change a package they
should do it without
Andrei Chis wrote
> Did you edited the configurations and their dependencies by hand? Since
> some time I never update them by hand, only use versioner
[Reminder]: Anyone using Git (like me for all my personal projects) can not
use Versionner because it does not handle Baselines. This will become
> On 08 Jun 2016, at 11:13, Andrei Chis wrote:
>
> Just a quick comment.
> Did you edited the configurations and their dependencies by hand? Since some
> time I never update them by hand, only use versioner to generate a new
> version for
2016-06-08 11:13 GMT+02:00 Andrei Chis :
> Hi Pavel,
>
> On Wed, Jun 8, 2016 at 11:05 AM, Pavel Krivanek
> wrote:
>
>> Hi,
>>
>> we had in the system circular package dependency between Catalog and
>> GTools and we decided to solve it by
Hi Pavel,
On Wed, Jun 8, 2016 at 11:05 AM, Pavel Krivanek
wrote:
> Hi,
>
> we had in the system circular package dependency between Catalog and
> GTools and we decided to solve it by simple moving of one method from one
> package to other one. However, these two
Hi,
we had in the system circular package dependency between Catalog and GTools
and we decided to solve it by simple moving of one method from one package
to other one. However, these two packages are external packages managed by
configurations. That means that we needed move the method, save
17 matches
Mail list logo