On 09/26/14 09:33 PM, Alexander Pyhalov wrote:
Guys, what do you think about this? First of all, why can't we just
make all incorporations
empty packages? What harm can it cause?
As I understand, consolidations are there to precisely lock versions of
interdependent packages, that are proved from testing before release, to
work nicely together, forming something that actually work, versus bunch
of disconnected applications where every change of one application can
break functionality of several other in strange ways.
As I understand, consolidations support developing distribution in TEAMS,
where each team tests and works on one consolidation to make it work
independently from another consolidations.
So it have two-fold reasons why it is great way of organizing teams and
testing of 'consolidated' packages. if someone wants to change some package,
one needs to contact maintainer of consolidation and to walk with change
with testing whole consolidation (opposite to affecting whole distribution).
I actually do not understand why having consolidations is a problem.
Simply, if some package needs to be updated in consolidation, it needs
to be tested
and as I understand only consolidation needs to be compiled , not whole
distribution, to test if changes works right. So consolidations seems
like good thing to me.
Currently we have the following incorporations:
pkg:/consolidation/X/[email protected]
I think can be relaxed
pkg:/consolidation/admin/[email protected]
I think can be relaxed
pkg:/consolidation/cacao/[email protected]
What is it?
pkg:/consolidation/cde/[email protected]
Perhaps, we could relax it, it seems to be something which is
going to stuck here, we can't do anything with it.
Or can we drop it one time?
Perheaps we can form rudimentary TEAMS to test them and to enhance their
presence.
Relaxing consolidations could lead to total breakage of whole distribution
and it undoes any previous testing
and updating every package separately leads to general lowering
distribution quality,
inability to effectively test and debug.
Short answer: we are NOT FreeBSD, if one wants to do it chaotically, it
is not OI/opensolaris way.
And I bet BDSs also have some hierarchy in changes and testing before
release,
and not just "update random package and see what happens".
What happens is random bugs all over the distribution, with no known
working inter dependencies
and unmaintainable mess. (That Hipster without releases and bunch of
consolidations removed or "relaxed" actually is now.
We need Teams for consolidations and teams for testing things.
And clear goal of publishing new /dev after Hipster testing cycle.
pkg:/consolidation/cns/[email protected]
What is it?
pkg:/consolidation/dbtg/[email protected]
What is it? Could it be relaxed?
We can Not just "relax" anything before testing updates in it.
True one needs people for it,
but no people are needed to make things started.
Or else, not knowing what consolidations or packages actually do,
leads to total confusion.
I think that also removing other consolidation previously was a big mistake,
also as I already explained.
pkg:/consolidation/gfx/[email protected]
What is it?
pkg:/consolidation/hcts/[email protected]
It's ddu. Perhaps, we can relax it?
pkg:/consolidation/install/[email protected]
There should be nothing wrong with this one, it's from slim_source.
pkg:/consolidation/jdmk/jdmk-incorporation
Some java libraries.. Is it closed? I think we can relax it.
pkg:/consolidation/man/man-incorporation
Perhaps we can just obsolete it? I see nothing depending on it.
pkg:/consolidation/nspg/nspg-incorporation
driver/network/ce is unlikely to be updated. I think, we can just
relax it.
pkg:/consolidation/osnet/osnet-incorporation
pkg:/consolidation/sic_team/sic_team-incorporation
I think, I'll relax it in the nearest future. Or is it better to
obsolete it?
pkg:/consolidation/solaris_re/solaris_re-incorporation
I think, we can relax it.
pkg:/consolidation/sunpro/sunpro-incorporation
I think we can relax it.
pkg:/consolidation/ub_javavm/ub_javavm-incorporation
We should do something with it. Do I understand correctly, that we
can't update
java now? Perhaps, we can relax it?
pkg:/consolidation/vpanels/vpanels-incorporation
I see that we have vpanels in oi-userland, but they are disabled.
Perhaps we should enable them? Who knows what is it? Some GUI admin
tool? Will it work
on OI and do we need them?
We actually need to use dev docs
Firstly is there somewhere TOTAL backup of opensolaris.org site
(including archive.org), it seems that maintaining opensolais descendent
distribution like OI needs reading at least some docs.
_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev
