opencog-dev team mailing list archive
-
opencog-dev team
-
Mailing list archive
-
Message #00438
Re: staging and main
2008/10/27 Cassio Pennachin <cassio@xxxxxxxxxxxxx>:
> Linas,
> No one is talking about overwriting your work. Follow policy and this issue
> disappears.
What can I say? I get the impression that we all have
a different idea of what the "policy" is. If we all
agreed as to what the policy was, and actually followed it,
then we wouldn't be having this conversation. Right?
Unfortunately, the last time we had this conversation,
it just sort of trailed off, with a "don't worry, be happy,
everything will merge". The fact that Joel raised this
issue shows that there is no policy that anyone is
actually following.
Thus, I proposed, just earlier today:
Policy point 1:
The various staging branches should rebase from
the main branch as often as possible, and, ideally, daily.
This seems "obvious" to me, and is what I've been
assuming all of this time, But you just argued against it.
I think that this should be made the first, foremost, part
of the "policy"; it directly addresses the merge problem
that Joel is having.
Policy point 2:
When code is "ready and working", it will be merged into
the main branch.
Seems like everyone agrees, but Gama's use of the word
"over-written" as a synonym for "merged" made me
jump.
>> and Gama implies that the staging area is unstable.
>
> I'm not aware of these implications. Staging is supposed to "work".
Well, that contradicts Gama's most recent email, where
he states that he is concerned about breakages, and how
things can be hard to fix in a timely manner. If some code
in someone's staging tree is "working", isn't it time to
merge?
There are many reasons for using development branches.
But once the code works, it should go into main.
What I was trying to say is that I do not want to use other
peoples staging branches, precisely because of the "it
might not work and we might not be able to fix it quickly"
problem. In particular, I don't really want to spend time
fixing bugs in things that used to work.
>> I strongly urge that this other mailing list be abolished. I see
>> no reason for two different mailing lists for opencog -- it
>> just makes everything cloudy and obscure.
>
> You keep bringing this up.
Because having two mailing lists for one subject doesn't
make sense. Because it leads to murky, unclear
communications, a non-transparent decision making
process, etc.
--linas
Follow ups
References