On 10/13/14 06:48 PM, Aurélien Larcher wrote:
Hi Nikola,
my impression was that making things easier (feasible ?) to build and
update is actually a priority to make a sustainable /dev possible.
IMHO focus should be on having hipster replicate what /dev does, for
instance have JDS in userland as mentioned in earlier threads.
Hi,
It is up to Hipster what to do with it's existence.
Minimum IS making possible of updating /dev, yes.
It is questionable are ALP , others willing to replicate anything at
all, actually.
So only sane thing that requires minimum effort could be getting Hipster
in line with /dev,
just enough to be able to do update. (Or make it from previous Hipster
states).
Otherwise not being able to update from /dev is not by mistake.
In the mean time if someone steps in to backport hipster's patches to
/dev that would be even better but I do not think it should be
Alexander's concern at all.
I think that backporting anything would be a lost cause here actually.
Let's leave backporting effort for the time when /release is made after
several /dev's.
That would be exact time for well centered backporting effort if long
support is the goal.
The goal could be integrating Hipster release cycle with /dev release
cycle and I think many people agreed on that.
/dev needs not to live separate life, to be able to utilize
Hipster changes.
I guess it just takes someone to make that happen now by backporting,
or make that happen in the short term by having a self-consistent
hipster that could be frozen to /dev.
If we make it that any /dev could be updated to precisely one frozen
Hipster,
then next thing would be releasing /dev that could be updated to from
Hipster.
Next /dev from that would be current Hipster in form of /dev .
To my understanding this is not yet the case for this latter but steps
are taken.
That includes also resurrecting working package manager GUI,
A few months ago I set up a git repository of the GUI part of okg
just before deprecation in Solaris, in case someone wants to take the
shot.
Great, put it somewhere or make it available somewhere or sent it so it
could be put on OI infastructure.
Packagemanager GUI and updatemenager are definitely what's needed.
Only thinkg for sure - in dev-Hipster-dev-Hipster cycle, not every
change to Hipster could make into the /dev.
Therefore, not every Hipster change can all together survive to live in
next Hipster, because they did not survive /dev cleaning.
That way weird and bad things will not accumulate in distro and freedom
to try out everything could be left.
_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev
