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.
_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev
