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
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
