[oi-dev] New Hipster ISOs are available

[Nikola M.]

On 10/14/14 08:43 AM, Alexander Pyhalov wrote:
> On 10/13/2014 20:21, Nikola M. wrote:
>
>> I still wait for your reply on idea that every Hipster update has new
>> 'entire' version changed, so someone testing could always update to
>> exact date and packages state to re-create environment where bug started
>> to happen.
>>
>
> Hello.
> Now entire is generated on the base of existing packages in the 
> repository. So it's technically hard to update it before publishing 
> new packages. If we update entire after publishing new package, we 
> have two problems.
> 1) New packages are not immediately available (before updating entire).
> 2) Before publishing entire we can't guarantee that it's installable. 
> Publishing uninstallable entire seems damn wrong.
>
> I think about the following. What if we create periodic task that 
> generates entire on the base of current state of the repository, 
> performs some heuristic checks on it, publishes it to separate 
> repository, temporary add this publisher and try to pkg update -n 
> entire? So we can check that current entire is installable and perhaps 
> even publish it to the main repository. But I'm still not convinced 
> that having non-empty entire incorporation is a good thing.
Well sure! If publishing new entire, means testing first if it is 
installable, then by all means.

Entire could be updated daily and/or weekly , but only if there were 
changes.
Changes from all entire changes during a week, could go to weekly 
entire. (and maybe monthly).
Entire numbering could be reset on every releasing to /dev,
only releasing to /dev should not be automatic and timed, but from 
entire that is tested and working.

Maybe updating new package in first place should be done, anyway, only 
if it is installable?
That relates then to higher quality of packages, because if updating a 
package requires to update other packages to make it working as a whole, 
that makes sense for existing of incorporations to remind people what 
depends on what horizontally.

One thing that now crossed my mind is that people actually need to 
publish new packages to test if they work, before fixing if they are 
installable from previous entire to next. So that entire could not be 
daily, but weekly,
because it would need some time to fix other packages to be installable 
as a whole in next entire.
If entire is weekly thing to happen, then updated packages that do not 
pass as installable should not be included in next entire. And that is 
weekly cleaning of packages before cleaning of packages for /dev.
(It now also crossed my mind that weekly cleaning before entire, could 
be automated e.g. if package is not installable, next entire is done 
without it)

It is important to move forward from entire version that is released as 
/dev (and/or renaming entire version to new /dev version name during 
Hipster cycle and then versioning it) ,
because that makes sure updated packages after every /dev are 
installable and that one can always jump from /dev to /hipster to test 
things and to make sure next /dev is installable from previous /dev  ,too.
(and updating from one /dev also needs testing before releasing /dev but 
that is much more easy to happen if weekly entire updates works)

Updating /dev in a faster pace this way, can motivate people to include 
themselves more in developing
and they could always do it, just by updating from latest /dev to latest 
/hipster entire.
It would also increase demands for /release and that would need also 
crew for maintaining it and would need customers for /release.