On 11/19/14 14:28, Andreas Lauser wrote:
Hi all,

On Wednesday 19 November 2014 18:11:03 Bård Skaflestad wrote:
On 2014-11-19 17:41, Jørgen Kvalsvik wrote:
This is what I propose instead:

Remove the repositories all-together and replace with a single opm repo.

So, you're proposing to undo the (more or less) careful separation of
responsibilities of user-facing features into autonomous but related
modules for the sake of build-time convenience for the *very* few OPM
developers?  That won't happen as long as I have any say in the matter.

I fully agree: For developers it is much better to keep things that are doing
different things separately and users are better served by `apt-get install
opm` (or whatever the equivalent of this is on Your Favorite Distribution/OS
(TM)).

Huh?  On gentoo I have these modules:

sci-physics/opm-autodiff [1]
     Available versions:  2013.10
     Installed versions:  2013.10(14:07:49 11/18/14)

[I] sci-physics/opm-core [1]
     Available versions:  2013.10
     Installed versions:  2013.10(14:05:50 11/18/14)

[I] sci-physics/opm-material [1]
     Available versions:  2013.10
     Installed versions:  2013.10(09:57:12 11/09/14)

[I] sci-physics/opm-polymer [1]
     Available versions:  2013.10
     Installed versions:  2013.10(14:07:07 11/18/14)

[I] sci-physics/opm-porsol [1]
     Available versions:  2013.10
     Installed versions:  2013.10(09:58:56 11/09/14)

[I] sci-physics/opm-upscaling [1]
     Available versions:  2013.10
     Installed versions:  2013.10(14:09:20 11/18/14)


I can recompile them, at the drop of a few routine maintenance words.

For Dune I have:

[I] sci-libs/dune-common [1]
     Available versions:  2.2.0 2.3.1 {mpi}
     Installed versions:  2.3.1(12:54:24 07/21/14)(-mpi)
     Homepage:            http://www.dune-project.org/dune
Description: Module for common files of DUNE, the modular toolbox for solving partial differential equations.

[I] sci-libs/dune-geometry [1]
     Available versions:  2.3.1
     Installed versions:  2.3.1(17:22:15 07/21/14)
     Homepage:            http://www.dune-project.org/dune
Description: Module for reference elements in DUNE, the modular toolbox for solving partial differential equations.

[I] sci-libs/dune-grid [1]
     Available versions:  2.3.1 2.3.1-r1 {X alugrid}
     Installed versions:  2.3.1-r1(17:24:14 07/21/14)(X -alugrid)
     Homepage:            http://www.dune-project.org/dune
Description: Module for grids in DUNE, the modular toolbox for solving partial differential equations.

[I] sci-libs/dune-istl [1]
     Available versions:  2.3.1 {X superlu umfpack}
     Installed versions:  2.3.1(12:54:47 07/21/14)(X superlu umfpack)
     Homepage:            http://www.dune-project.org/dune
Description: Module for iterative solvers of DUNE, the modular toolbox for solving partial differential equations

[I] sci-physics/dune-cornerpoint [1]
     Available versions:  2013.10


Easily, we can add Petsc and other math codes. The flags (in parenthesis) are set according to what options you want and other codes to be included or excluded. It's so modular, you just develop a simple script for the ebuild. They are like an "enhanced shell script".
Obviously a work in progress. Very easy to support and include the
latest patches. In face the upcoming new release of gentoo ebuilds
will allow a user to include and compile in any patches the want. No github, repos, waiting; no nothing. Put the patch in the source-dir
and compile away.  Gentoo is the best distro for code development,
bar *nothing*.

There are no limits to the coolness of this approach. Developer-37 uploads patches, the user "syncs" and the rebuilding of the module allows inclusion or not. BANG the user is concurrent with the latest codes.

NOTHING is simpler for keeping the user community abreast and current with the latest patches. Rolling out new, stable binaries is a major pain and devs only do that every few months or so.


Seriously, RedHat, *buntu, debian etc etc, SUCK when it comes to keeping the users in the loop on new codes. Hey, it also keeps is so other devs and potential new devs can trivially build executable binaries, as they like, when they like, as current as the latest patched releases..... View sources is trivial and concurrent.


For reference, the Linux kernel, which is a much larger project than
opm, only use one repo.

Clients are expected to use the entire Linux tree as whole when doing
anything with the Linux sources.  That assumption doesn't hold in the
case of OPM.

These comparison are *asinine* at best. The kernel supports direct hardware device drivers. Nothing is OPM is close to that level of sophistication or diverse need. Heck, we cannot even get several platforms of linux supported by OPM modules because the overall,
or lack thereof, architecture is abysmal, at best.

Note that Jørgen's argument equally applies to the whole software stack of the
OS: Put the kernel, the C library, the compiler, the GUI and whatnot into one
giant repo and compiling the whole thing gets much simpler. (now, find the
mistake. ;))


I'm all for empowering the devs each with their own fiefdom, as they believe they need. It's pointless to argue this. It's akin to argueing who is the most beautiful women of all time (we all that's Halle Berry right?).....

Each and every code development block should be allowed to do as they like. That said, supporting what to compile and when and with which (flags) options definitely needs to simplified and standardized. That should be the venue of the *USER*, except for the few core modules.


What you currently have is what professional software developers call
"a kludge".

That said, I'm a really a BIG FAN of OPM. I think everyone is GREAT.
But, there are some "poopie diapers" that need to be removed. Some time needs to be devoted to cleaning up this mess. THEN this project will explode with vitality. It's your repo(s) so fix the mess so it is readily useful to a wider audience of coders and users. You do that, then We'll finish up the gentoo ebuilds. That will bring a horde of folks curious and who can have the latest version, with a few keystrokes.


Then things like "security testing" (just to mention one of a myriad of things) can begin in earnest.

OK?

cheers
   Andreas


hth,
James



_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm

Reply via email to