[Sorry to cross-post to oi-dev but wanted to reply to the thread]
On Apr 18, 2021, at 6:07 AM, Andreas Wacknitz <a.wackn...@gmx.de> wrote:
>
> Am 18.04.21 um 02:37 schrieb Austin Kim:
>> On Apr 17, 2021, at 7:22 PM, Till Wegmueller <toaster...@gmail.com> wrote:
>>> Hi Gary
>>>
>>> I use Postgres and extensions for all Applications I develop professionally
>>> and privately.
>>>
>>> We use mostly 12 and upwards 13 being the standard and I am waiting for 14
>>> to hit. The last Bugfix release for 9.5 was on 2021-02-11 so quite recently.
>>>
>>> I would love to have 13 and modern 12 packaged, especially as we have a
>>> build server for them sponsored by the Oi community. So we know it builds
>>> even on current develop.
>>>
>>> My preference for the record is to have 13, 12 and 11. Older ones should
>>> only be used for people still needing them. AWS only offers those in their
>>> offerings as well, so not many people will want 10 or older.
>>>
>>> -Till
>>>
>>> On 17.04.21 18:46, Gary Mills wrote:
>>>> OI currently has postgresql versions: 95 96 10 11 12 . The OI
>>>> default, in shared-macros.mk, is 95 . However, the postgresql
>>>> developers report that 95 is unsupported, but 13 is available and
>>>> supported. Something has to change in OI to move forward with
>>>> postgresql.
>>>> Here are some actions that could be taken with OI. We could change
>>>> the default version to 10. I, myself, would prefer 11. We could
>>>> obsolete 95. I'd prefer obsoleting 95 and 96. We could add version
>>>> 13, but only after 96 is obsoleted. We should limit the number of
>>>> postgresql versions in OI, after all. Finally, we could make no
>>>> obsoletions or additions, retaining even the unsupported 95. Which
>>>> would you prefer?
>>>> I have not investigated two questions. Perhaps you can tell me? What
>>>> are the consequences of obsoleting 95? What are the consequences of
>>>> the default change?
>> Hi,
>>
>> Sorry for posting to this list as I’m only an OpenIndiana user, not a
>> developer, but PostgreSQL is the DB I use most.
> This is perfectly fine.
> I just want to chime in here and say: You don't need to be a developer
> in order to get involved in OpenIndiana!
> Of course it is helpful to know some programming languages and build
> systems. But many for aspects you don't need to be a professional
> programmer.
>
> At the moment we lack volunteers in almost all areas, even those not
> related to updating packages. Eg. we need people to enhance or update
> our documentation,
> we need testers and of course people who care for some packages.
>
> Nobody started as an expert in any of these areas. I am willing to help
> people to get involved, eg. we can have video conferences where I can
> demonstrate and teach how to update packages.
>
> Of course you need to devote some resources (time, build or test
> environment, ...). I can assure you that you will learn a lot about
> OpenIndiana, Solaris and other operating systems.
> And you will see some insanity related to software development,
> especially open source software development where projects make heavy
> changes (like change the build system) in minor or even micro releases.
>
> Andreas
This is the nicest message I have ever seen on any mailing list.
One of the things that attracted me to OpenIndiana (apart from Sun Microsystems
having been so generous and selfless funding UNIX labs in underserved CS
departments, engineering schools, and universities, not just in the United
States but even around the world—I once visited a country in the Middle East
where annual per capita GDP was under US $1000 and walked into an engineering
school lab where I was surprised to see all the servers and workstations were
donated by Sun Microsystems with a plaque from Sun on the wall) (and also apart
from the VERY heavy lift on Sun Microsystems’ part to open-source
OpenSolaris—which they never had to do but to me just exemplifies the core
values and character of the company) was that unlike the *BSDs no one working
on OI AFAIK receives any financial compensation for their contributions; it
seems to be purely a labor of (often thankless) love, which is inspiring.
Personally in the future as time permits I hope to be able to contribute to
updating the Project’s WWW site pages and then work on updating OI’s online
docs to reflect the current state of OI. I really would like to see OI’s
online docs and WWW content better reflect all the hard work and effort all the
OI developers have been putting into it, from Alasdair Lumsden to Alexander
Pyhalov to everyone contributing today.
As purely an OI user, I have a few initial suggestions (read: wishlist items:)
0. The creation of a new, dedicated “oi-doc” mailing list for future use for
an OI “Documentation Project” team and others interested in contributing
to/updating/revamping OI documentation and user guides (this might reduce
cluttering up oi-dev with future documentation-related threads);
1. Going forward, not only announcing new Hipster releases on
OpenIndiana-announce, but also major security patches (for example, when
CVE-2021-3156 related to _sudo_ was patched at the end of January/beginning of
February, at the time I was subscribed only to OpenIndiana-announce and not to
oi-dev or any of the Illumos mailing lists and didn’t find out about the patch
until happening to come across it on OmniOSce’s mailing list); and
2. I know this is totally random and off-topic, but when naming OI IPS
packages à la (from Till W.’s earlier e-mail):
PACKAGE PUBLISHER
pkg:/database/postgres-common@9.5.24-2020.0.1.0 openindiana.org
pkg:/service/database/postgres-10@10.16-2020.0.1.0 openindiana.org
pkg:/service/database/postgres-11@11.10-2020.0.1.0 openindiana.org
pkg:/service/database/postgres-12@12.5-2020.0.1.0 openindiana.org
pkg:/service/database/postgres-95@9.5.24-2020.0.1.0 openindiana.org
pkg:/service/database/postgres-96@9.6.20-2020.0.1.0 openindiana.org
what would you all think about possibly adopting an OpenIndiana convention that
going forward the version number part following the “@” be named according to a
standard format such as the following:
…@Maj.Min[.Rev]-YYYY.M.D.B
where the Major, Minor, and (if present) Revision numbers are taken
from the corresponding version number of the upstream source;
where YYYY, M, and D are the year, month, and day whereon the upstream
source was downloaded by the IPS package builder; and
where B could just be incremented from 0 in the case of subsequent IPS
package releases built from the same upstream source version (that was
downloaded on that particular YYYY.M.D)?
Having the full YYYY.M.D date code would be helpful to users considering
installing and/or upgrading to that version by quickly indicating what the date
was as of which the upstream source used was current, which could potentially
be helpful in the case of, for example, trying to figure out if the package
likely includes a security patch incorporated upstream on a given date.
Austin
“We are responsible for actions performed in response to circumstances for
which we are not responsible.” —Allan Massie, _A Question of Loyalties_, 1989
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
