8 Nov
2011
8 Nov
'11
6:33 p.m.
to have a default select: [:each | 'pac*' match
and to avoid to have ' in drop box and this is not in the latest version of
moose.
How do we know merge process work in moose?
Stef
8 Nov
8 Nov
7:08 p.m.
New subject: we fixed some merlin packages last friday but there are not in Moose
We udpated the configuration of merlin
So that satble in 1.5 and development is 1.6 and 1.6 contains our changes
On Tue, Nov 8, 2011 at 6:33 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
to have a default select: [:each | 'pac*'
match
and to avoid to have ' in drop box and this is not in the latest version
of moose.
How do we know merge process work in moose?
Stef
9 Nov
9 Nov
8:15 a.m.
New subject: we fixed some merlin packages last friday but there are not in Moose
This is precisely the problem I was referring to when I said that it is not clear what is
the best solution when versioning Moose with Metacello. What we do not want is lose
versions like this along the way.
Cheers,
Doru
On 8 Nov 2011, at 19:08, Usman Bhatti wrote:
We udpated the configuration of merlin
So that satble in 1.5 and development is 1.6 and 1.6 contains our changes
On Tue, Nov 8, 2011 at 6:33 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
to have a default select: [:each | 'pac*' match
and to avoid to have ' in drop box and this is not in the latest version of moose.
How do we know merge process work in moose?
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Beauty is where we see it."
13 Nov
13 Nov
9:02 a.m.
New subject: we fixed some merlin packages last friday but there are not in Moose
we do not lose anything if we have a clear process.
Right now I have no idea what is the process.
And just publishing a package and thinking that it will be loaded leads to the fact that
we cannot load moose anymore.
There is nothing like a free lunch and we could script metacello to generate support our
process.
It makes me smile because we say that we are tool builder and we still do not script the
API of metacello.
Stef
This is precisely the problem I was referring to when
I said that it is not clear what is the best solution when versioning Moose with
Metacello. What we do not want is lose versions like this along the way.
Cheers,
Doru
On 8 Nov 2011, at 19:08, Usman Bhatti wrote:
We udpated the configuration of merlin
So that satble in 1.5 and development is 1.6 and 1.6 contains our changes
On Tue, Nov 8, 2011 at 6:33 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
to have a default select: [:each | 'pac*' match
and to avoid to have ' in drop box and this is not in the latest version of moose.
How do we know merge process work in moose?
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Beauty is where we see it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:20 p.m.
New subject: we fixed some merlin packages last friday but there are not in Moose
Hi,
On 13 Nov 2011, at 09:02, Stéphane Ducasse wrote:
we do not lose anything if we have a clear process.
Right now I have no idea what is the process.
And just publishing a package and thinking that it will be loaded leads to the fact that
we cannot load moose anymore.
This is because of the mess introduced by having hardcoded versions during development.
There is nothing like a free lunch and we could script
metacello to generate support our process.
It makes me smile because we say that we are tool builder and we still do not script the
API of metacello.
You wrote a chapter on Metacello. So, you are a great candidate for providing the support
:).
Cheers,
Doru
Stef
--
www.tudorgirba.com
"When people care, great things can happen."
This is precisely the problem I was referring to
when I said that it is not clear what is the best solution when versioning Moose with
Metacello. What we do not want is lose versions like this along the way.
Cheers,
Doru
On 8 Nov 2011, at 19:08, Usman Bhatti wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev We udpated the configuration of merlin
So that satble in 1.5 and development is 1.6 and 1.6 contains our changes
On Tue, Nov 8, 2011 at 6:33 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:
to have a default select: [:each | 'pac*' match
and to avoid to have ' in drop box and this is not in the latest version of moose.
How do we know merge process work in moose?
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Beauty is where we see it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:05 p.m.
New subject: we fixed some merlin packages last friday but there are not in Moose
Hi,
On 13 Nov 2011, at 09:02, Stéphane Ducasse wrote:
sure! Now you will probably not like the result. I still do not understand what was wrong
with putting versions.
I wonder why I wrote it since nobody reads it.
I will fork the ConfigurationOf and see but I have no time for that now.
Stef
we do not lose anything if we have a clear
process.
Right now I have no idea what is the process.
And just publishing a package and thinking that it will be loaded leads to the fact that
we cannot load moose anymore.
This is because of the mess introduced by having hardcoded versions during development.
There is nothing like a free lunch and we could
script metacello to generate support our process.
It makes me smile because we say that we are tool builder and we still do not script the
API of metacello.
You wrote a chapter on Metacello. So, you are a great candidate for providing the support
:).
10:19 p.m.
New subject: we fixed some merlin packages last friday but there are not in Moose
On 13 Nov 2011, at 22:05, Stéphane Ducasse wrote:
It was a joke :)
Hi,
On 13 Nov 2011, at 09:02, Stéphane Ducasse wrote:
sure! we do not lose anything if we have a clear
process.
Right now I have no idea what is the process.
And just publishing a package and thinking that it will be loaded leads to the fact that
we cannot load moose anymore.
This is because of the mess introduced by having hardcoded versions during development.
There is nothing like a free lunch and we could
script metacello to generate support our process.
It makes me smile because we say that we are tool builder and we still do not script the
API of metacello.
You wrote a chapter on Metacello. So, you are a great candidate for providing the support
:). Now you will probably not like the result. I still do
not understand what was wrong with putting versions.
Nothing. Just doing it manually was too error prone and I could not keep up with it. And
for development, I want to continue to push for the last version of all packages.
The thing that would work well with our process is to produce a configuration for what is
in the image at some moment. But, it is difficult to produce with nested configurations.
So, in the meantime we should traverse the Configuration and produce a simple flat Gofer
script. This could be a nice bridge solution.
I wonder why I wrote it since nobody reads it.
I will fork the ConfigurationOf and see but I have no time for that now.
Do not fork it :). Just add publish on top.
Doru
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
10:51 p.m.
New subject: we fixed some merlin packages last friday but there are not in Moose
Now you will probably not like the result. I
still do not understand what was wrong with putting versions.
Nothing. Just doing it manually was too error prone and I could not keep up with it. And
for development, I want to continue to push for the last version of all packages. The thing that would work well with our process is to
produce a configuration for what is in the image at some moment. But, it is difficult to
produce with nested configurations. So, in the meantime we should traverse the
Configuration and produce a simple flat Gofer script. This could be a nice bridge
solution.
ok I see
I wonder why I
wrote it since nobody reads it.
I will fork the ConfigurationOf and see but I have no time for that now.
Do not fork it :). Just add publish on top.
Doru
Stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
14 Nov
14 Nov
7:51 a.m.
New subject: we fixed some merlin packages last friday but there are not in Moose
Hi,
what does it mean?
Because if we start to freeze the versions then getting the last version will get more
difficult.
Having fixed versions will not interfere with having a baseline that will be loaded by
Jenkins. The idea is that versions will not be essential for our development. They will
only offer the possibility to load past versions.
Cheers,
Doru
I will fork the ConfigurationOf and see but I have no
time for that now.
Do not fork it :). Just add publish on top.
10:49 a.m.
New subject: we fixed some merlin packages last friday but there are not in Moose
Ok I see
so you load baseline and we snapshot version.
Stef
On Nov 14, 2011, at 7:51 AM, Tudor Girba wrote:
Hi,
what does it mean?
Because if we start to freeze the versions then getting the last version will get more
difficult.
Having fixed versions will not interfere with having a baseline that will be loaded by
Jenkins. The idea is that versions will not be essential for our development. They will
only offer the possibility to load past versions.
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I will fork the ConfigurationOf and see but I have no
time for that now.
Do not fork it :). Just add publish on top.
10:54 a.m.
New subject: we fixed some merlin packages last friday but there are not in Moose
Precisely.
Doru
On Mon, Nov 14, 2011 at 10:49 AM, Stéphane Ducasse <
stephane.ducasse(a)inria.fr> wrote:
Ok I see
so you load baseline and we snapshot version.
Stef
On Nov 14, 2011, at 7:51 AM, Tudor Girba wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
Hi,
>>> I will fork the ConfigurationOf and see but I have no time for that
now.
>>
>> Do not fork it :). Just add publish on top.
>
> what does it mean?
> Because if we start to freeze the versions then getting the last
version will
get more difficult.
Having fixed versions will not interfere with having a baseline that
will be
loaded by Jenkins. The idea is that versions will not be essential
for our development. They will only offer the possibility to load past
versions.
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4787
days inactive
4793
days old
10 comments
3 participants
participants (3)
-
Stéphane Ducasse -
Tudor Girba -
Usman Bhatti