On 11/16/15 12:02 PM, Stefan Müller-Wilken wrote:
Hmmm... so the better approach for Internet facing nodes is to move on to
/hipster but be defensive in your update policy? Because with what you say and
in contrast to Udo, I'd rather call /dev than /hipster going nowhere as more
and more /dev packages have reached EOL in their respective projects.
One thought: would it be possible to tag certain Hipster revisions as 'de-facto
stable' and publish a small tutorial how to upgrade to such point releases? I
feel we'll need a sort of stable ground to convince people to put faith in OI.
Yes, that is a valid idea, best ting is to make new /dev out of hipster
and at some frozen hipster state that is tested for upgrade and works
and that would land into the /dev, while hipster continues on it's course.
It needs involvment of the people in making OI and not only using it.
So selecting contribution area , depending on abilities, time and
expressing opinions, documenting and/or financing it, would be the best.
Lurking at the Oi Wiki
(http://wiki.openindiana.org/oi/OpenIndiana+Wiki+Home) and joining
regularly on Freenode's #openindiana and #oi-dev with Xchat or other ITC
client could make targeting contributing areas more clear.
There are some problems/projects to achieve that:
-Source code availability: Having all source code for all components
available, versioned on Openindiana servers, and Oi build from them,
before updating to such hipster-grown /dev.
-Binary compatibility for legacy applications: If hipster changes land
into /dev ,
one can not expect to just continue running existing packages, but maybe
inside branded zone with newest studio compiled /dev packages for
compatibility with legacy applications.
-Testing hipster with updating form dev and fixing current state of
hipster: Hipster is not de-facto stable ATM (maybe it is for the server
part), and needs aether upgrades and new users of it and contributors to
come to a state where it could become new /dev.
-Downgrading packages ability in Hipster: Have ability to downgrade
packages to the versions that used to work before refreshing it or
contribution, before newly intoduced bug is fixed.
That also goes with usign 'entire' for jumoing in between package states
to be able to do testing before pushing it in /dev (there is 'entire'
now for oi-userland)
-Mindset about where hipster and /dev come together:
If /dev is for general use and deployment with bug reporting in between
/dev, and hipster is for development in between 2 /dev releases,
then if one looks that way and new /dev releases come it timely manner ,
not too often and not less then 6 times a year,
then the release and testing cycle could work, providing people actually
update using Boot environments as fail-safe and report bugs in between.
Hipster could land into /dev more often and that woudl be better from
deveopment and testing point and can require less people, but it would
need more involvment of existing peopel in keeping quality high.
This talk about upgrading /dev should be happening 2 years ago instead
of now as I mentioned I used to upgrade form /dev to hipster form 151a8
and that was a moment to freeze it,
but now, thankfully to great work of Hans Rosenfeld thah moment is here
again.
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
