yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxxxxxx>]

Thanks Jerôme, Janek, and Anton, for feedback.
I'll try and address some questions.

@Jérôme
The objective of this thread is not to measure available human ressource 
but to use it more efficiently, instead. Recent git activity can provide 
us with example cases but it is not so relevant overall.

/> Would we have new features using gitlab ? I got more and more used to 
github and like it for its commit comments / pull requests / issues. We 
actually barely / > do not use those... ////but maybe this could change 
in the future. Would we have the same on gitlab ? (Yes ?) //
///
Yes, definitely most features of github have equivalent things in gitlab.

/> I also see there are gtilab versions that require a fee ([1] in your 
email). Are we going to use (for the integration framework) a free 
version ?//
/
Exactly like github. Not an issue, we use free version in both cases.

/> 1. Regarding the possibility to update trunk from other branchs only: 
this would mean every dev should make a public branch before pushing to 
trunk/master ? //
///
Everyone should work on a branch then merge, yes (public or not, it 
doesn't matter). It is good practice anyway and I think we need to move 
in this direction with or without gitlab. That's actually what many devs 
do already, see e.g. the yade-mpi branch 
(https://github.com/bchareyre/yade-mpi).
When pushing to master there is no way to see the revision before 
accepting it. That is, it will be built and uploaded to public repos for 
everyone to download, without control. That would be fine if test 
coverage was approaching 100% but we are probably closer to 10%, it is 
not a safe situation.
With merge requests revisions can be shown before entering the 
build/release loop.
/
> I think a more controlled / pre-assessed way of doing things is not 
be possible with our current HR.
/
The current post-assessment approach is not necessarily less time 
consuming and it does not seem to guarantee stability, hence why our HR 
are seeking improvement.
/
// > //people can not do otherwise than looking closely at things when 
they are directly concerned (which is not always obvious to realize by 
the way).//
/
A maintainer can't be happy with watching just a short selection of 
files. The whole project needs to be maintained consistently.

/> I'm thus 100% happy with our current way of doing things/

I am not.
On the one hand, post-assessment implies reverts and there seem to be 
resistance against that.
On the other hand, post-assessment without reverts would mean no 
assessment. We (Grenoble folk) are not going to spend human and cpu time 
on website and gitlab framework, just to host an unmaintained project.
If someone wants to start an experimental branch where everyone can push 
with no control it is an interesting experiment (the main question being 
how long it will take to get broken) but the build framework will 
probably not checkout such branch.
We need a stable codebase to protect users and to be able to develop 
further (various code couplings, MPI parallelization,...).

>/I understand this current way of doing things is stressful for 
computing cluster users, but I see this stress being inherent to an 
evolving free, open-source code that comes "with no warranty"... /

That's why linux doesn't work on clusters. The "no warranty" clause 
explains it all. :)
Finally, I realize that your response is pushing for more control. :)


@Janek

/> When I will start pushing fuild calculations stuff it will be lots of 
tiny/
//
/> commits :) //I suppose it will be easier for me to merge everything/
//
/> locally, then push it. //Do you then prefer to review a rather large 
merge?/

A lot of small commits is the essence of git. Obviously a big merge is 
easier to read as a whole than one commit every two days during a year 
or so. :)

/> If so, then do you prefer that I push a whole separate fuild branch?//
///
Absolutely. It is then possible to compare the two branches and to see 
all revisions from the accumulated commits.

Cheers

Bruno