<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/13/14 06:48 PM, Aurélien Larcher
wrote:<br>
</div>
<blockquote
cite="mid:CAHMq6q1AxKQY7-K=ZomyLtfFxn88ieryXOjnW-4-LsQzGhYnrQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>Hi Nikola,<br>
</div>
my impression was that making things easier (feasible ?) to
build and update is actually a priority to make a
sustainable /dev possible.<br>
</div>
IMHO focus should be on having hipster replicate what /dev
does, for instance have JDS in userland as mentioned in
earlier threads.<br>
</div>
</div>
</blockquote>
Hi,<br>
It is up to Hipster what to do with it's existence. <br>
Minimum IS making possible of updating /dev, yes.<br>
<br>
It is questionable are ALP , others willing to replicate anything at
all, actually. <br>
So only sane thing that requires minimum effort could be getting
Hipster in line with /dev, <br>
just enough to be able to do update. (Or make it from previous
Hipster states).<br>
Otherwise not being able to update from /dev is not by mistake.<br>
<br>
<blockquote
cite="mid:CAHMq6q1AxKQY7-K=ZomyLtfFxn88ieryXOjnW-4-LsQzGhYnrQ@mail.gmail.com"
type="cite">
<div dir="ltr">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.<br>
</div>
</blockquote>
I think that backporting anything would be a lost cause here
actually.<br>
<br>
Let's leave backporting effort for the time when /release is made
after several /dev's.<br>
That would be exact time for well centered backporting effort if
long support is the goal.<br>
<br>
The goal could be integrating Hipster release cycle with /dev
release cycle and I think many people agreed on that.<br>
<blockquote
cite="mid:CAHMq6q1AxKQY7-K=ZomyLtfFxn88ieryXOjnW-4-LsQzGhYnrQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div>
<div>
<div class="gmail_extra">
<div dir="ltr">
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">/dev needs not to
live separate life, to be able to utilize Hipster
changes.<br>
</blockquote>
<div>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.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
If we make it that any /dev could be updated to precisely one frozen
Hipster,<br>
then next thing would be releasing /dev that could be updated to
from Hipster.<br>
Next /dev from that would be current Hipster in form of /dev .<br>
<blockquote
cite="mid:CAHMq6q1AxKQY7-K=ZomyLtfFxn88ieryXOjnW-4-LsQzGhYnrQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div class="gmail_extra">
<div dir="ltr">
<div>To my understanding this is not yet the case for
this latter but steps are taken.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><br>
That includes also resurrecting working package
manager GUI,<br>
</blockquote>
<div>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.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
Great, put it somewhere or make it available somewhere or sent it so
it could be put on OI infastructure.<br>
Packagemanager GUI and updatemenager are definitely what's needed.<br>
<br>
Only thinkg for sure - in dev-Hipster-dev-Hipster cycle, not every
change to Hipster could make into the /dev.<br>
Therefore, not every Hipster change can all together survive to live
in next Hipster, because they did not survive /dev cleaning.<br>
That way weird and bad things will not accumulate in distro and
freedom to try out everything could be left.<br>
<br>
</body>
</html>