[oi-dev] [OpenIndiana-discuss] Moving on with postgresql

[Austin Kim]

[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.Wacknitz at gmx.de> wrote:
> 
> Am 18.04.21 um 02:37 schrieb Austin Kim:
>> On Apr 17, 2021, at 7:22 PM, Till Wegmueller <toasterson at 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 at 9.5.24-2020.0.1.0     openindiana.org
	pkg:/service/database/postgres-10 at 10.16-2020.0.1.0  openindiana.org
	pkg:/service/database/postgres-11 at 11.10-2020.0.1.0  openindiana.org
	pkg:/service/database/postgres-12 at 12.5-2020.0.1.0   openindiana.org
	pkg:/service/database/postgres-95 at 9.5.24-2020.0.1.0 openindiana.org
	pkg:/service/database/postgres-96 at 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