[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Moving pkgsrc-wip away from SourceForge
A little perspective from my corner of the open source world...
It's been stated in this thread that most advanced VCS features are not
that critical to pkgsrc[-wip]
given the typical usage. Based on that, I would argue for something
that's easy to learn and
offers and efficient work flow for the average end user.
I agree that technical merits should be the top priority, but it may be
the case that most of the newer
VCS systems more than meet our requirements, hence we can focus on using
something that's inviting
to both existing and potential new packagers.
I work in a University environment with students and researchers, many
of whom are very sharp, but not computer scientists.
A few years ago, I chose to focus on subversion for their sake, despite
it's limitations and bugs at the time, because I think the
centralized model is easier to pick up and the basic commands are
intuitive and fast. Since then, many of the
limitations have been addressed (e.g. better merging logic).
I'm not arguing specifically for subversion here, but simply arguing to
keep options besides git on the table.
I'm trying to promote the use of pkgsrc in computational science,
because I think it offers the best
foundation of any conceivable method for managing scientific software:
1) It works well on RHEL-based platforms, which currently dominate
HPC and HTC
2) It's cross-platform, so every new package created can be leveraged
by BSD, Mac, and other users
3) It has a large, stable, up-to-date base of packages that most
scientific software depends on
Man-hours are everything for us. Researchers can't afford to hire
programmers and lack the time and skills
to port everything themselves.
A lot of time is wasted in the research community on redundant effort
going into multiple packaging systems,
systems that simply don't work well (e.g. Yum, with it's many older
libraries and tools that are incompatible with
the latest open source software) and use of the cave-man installation
method (manually download, unpack, patch, etc.)
A lot of research simply never happens because researchers give up on
trying to install the software they need.
Pkgsrc solves all these problems in theory, but we need to attract more
packagers from the scientific research community
to create an maintain a critical mass of scientific software packages.
A VCS that doesn't feel like a road-block to them would be
one important step forward to help the cause.
On 7/7/15 3:58 AM, Thomas Orgis wrote:
Am Tue, 7 Jul 2015 13:37:44 +0530
schrieb Mayuresh <mayuresh%acm.org@localhost>:
I do not wish to digress, but reminds of debates in various Linux mailing
lists about adoption of systemd, with one of the factors being "every
distro now uses it, so that all sysadmins will be familar with it".
I join in digressing: Another factor is "other upstream code starts to
depend on it and it will be a royal pain to patch things up to work
without systemd, as we cannot easily keep up with the development pace
and its hunger for functionality". Personally, I fear that basically
every distro will have to ship it to support the expected userspace
software stack eventually.
So far *BSDs are not bitten by the systemd bug (at least to the
extent I know). But looks like there is a similar thought pattern (of
using what many people know) emerging.
I would like to put less emphasis on that (as do you, I presume), but
don't ignore technical reasons why something is more popular. Heck, I'm
not arguing that pkgsrc must switch git, but you cannot ignore that at
least Subversion brings lots of workflow improvements over CVS already.
Granted, the lightweight working copy is one point that SVN lacks. I am
actually intrigued by this recent discussion about CVS (I never
imagined that I would look at CVS features still in 2015) to push for
SVN supporting that. I would ship my release tarballs with a .svn
folder for most easy access to the repository, just like pkgsrc does.
Jason W. Bacon
If a problem can be solved,
there's no need to worry.
If it cannot be solved, then
worrying will do no good.
Main Index |
Thread Index |