yade-dev team mailing list archive

[Janek Kozicki <janek_listy@xxxxx>]

> Sergei D. wrote: On Fri, Mar 18, 2011 at 11:25 AM, 
> >
> > If no new leader, we need some rules for commits.
> > It is important if new people will join to develop.  And it is important for
> > current command, because no one has so many skills as Vaclav. He did review
> > all commits, so everyone can be calm, that does not disrupt Yade. So, we
> > need a review's system for commits (as for articles, for example). Each
> > commit should be approved by one (or two) from command. Main trunk will have
> > only approved commits. Dev trunk will have commits for approve. Merging a
> > main with a dev should be done by other from command, not one who did a
> > commit.
> > What do all think about this?

Anton Gladky said:     (by the date of Fri, 18 Mar 2011 12:41:06 +0100)
> Hi, all,
> 
> I decided to start a new thread, answering on Sergei's email.
> I completely agree with him about controlling any commits. Fighting
> with bugs is really difficult and long-time work, and we should
> minimize those efforts, focusing on more useful work.
> 
> I suggest:
> * create a new team, something like yade-security, yade-approvers etc.
> * create a branch, owned by this team.
> * all commits to this new branch should be done by somebody from this team.
> 
> Yade buildbot needs to control and compile each revision, making
> corresponding tests after compiling (like it is now). We should also
> care about adding some more additional tests to --checks section.
> 
> All comments and discussions are very welcome.
> Anton

As we can see there is a general reluctance in taking voice in this
discussion. Probably because not many people want to volunteer to
"take the responsibility". A single leader is a good thing, because
he manages and takes care.

Look at me for example - I am on the side track for about two years now.
I cannot review the commits not only due to lack of time (which is
true), but also because I am re-discovering what has happened to yade.

Even though the general OO architecture is my design, the changes
that happened to it make it a quite different code. When I browse and
search for something I immediately recognize my original OO
structures, but I must search to know where something should belong,
I do not know instantly beforehand - just from my memory.

From what I see, and what is happening I would say that eligible
people are Bruno, Sergei and Anton.

Although if Jerome, Vincent, Chiara, Boon, Emanuele, Luc Sch., Jan,
Luc Sib. or others will volunteer I see no reason to reject. Which
takes us back to the team which is already present.


However, is that the development model that will be most efficient?

It is similar to making a -stable and -dev branch, where only few
people can commit to -stable.

I must say that I have 100% trust in everyone that does commits to
yade, due to plain logic: nobody will want to damage it. People can
only make mistakes, and that is why we are using revision control
system. And that's why we are (more or less) watching what is going
on.

Anton Gladky said:     (by the date of Fri, 18 Mar 2011 12:41:06 +0100)
> I suggest:
> * create a new team, something like yade-security, yade-approvers etc.
> * create a branch, owned by this team.
> * all commits to this new branch should be done by somebody from this team.

If you like this development mode, it makes you comfortable, and you
believe that this will make us more productive, then go for it.
We just need to complete the team.


> Yade buildbot needs to control and compile each revision, making
> corresponding tests after compiling (like it is now). We should also
> care about adding some more additional tests to --checks section.

the automation already present in whole framework is already
very impressive. Adding more --checks will be very useful, no doubt
about that.

I think that one of most important things is keeping scripts up to
date, because that is what people are trying first when they install
yade. This is not fully automated, yet, to my knowledge.


best regards
-- 
Janek Kozicki                               http://janek.kozicki.pl/  |