|
List Info
Thread: Open Source software and OpenSolaris. What is the deal?
|
|
| Open Source software and OpenSolaris.
What is the deal? |
|
2007-05-03 21:58:00 |
I've added companion-discuss to the discussion. And I've
added Laca
from the JDS group, since he's working on a project[1] that
should make it
easier to keep third-party apps current. For those folks:
this thread
was started by Brian Gupta's observation[2] that there are
several
overlapping projects that deal with third-party open source
code and
(Open)Solaris and maybe things could be done more
efficiently.
>>>>> "jek3" == Joseph Kowalski
<jek3 sun.com> writes:
jek3> I think the concept of CCD is simply bad. We
should not be
jek3> providing a recompilation and packaging service. We
should be
jek3> providing assistance to the ultimate code
maintainers to provide
jek3> Solaris "packages" just like they provide
RPMs (or whatever) for
jek3> Linux. Let's turn our "recompile" junkies
into "Solaris Packaging
jek3> Evangelists" (easier said than done -
different skill set - but
jek3> hopefully you get the idea).
The upstream maintainers will need Solaris boxes (SPARC and
x86) in
order to produce Solaris packages. I'm skeptical that they
will be
enthusiastic about this.
jek3> Second, there is an unavoidable latency introduced
by placing a
jek3> "CCD" service in the loop.
Up through Solaris 10 the Companion had a horrible latency
problem,
because we only shipped new bits with each Solaris update
release.
Now it has a smaller latency, which is the time to download
the latest
upstream source, tweak local patches as needed, rebuild and
sanity-test,
then push new packages to opensolaris.org.
jek3> The Linux distros don't have this latency.
They didn't have the first one that I mentioned, but I
believe they do
have the second one.
mike
[1] http://mail.opensolaris.org/piperm
ail/companion-discuss/2007-April/000522.html
[2] http://mail.opensolaris.org/pipermail/sf
wnv-discuss/2007-May/000380.html
_______________________________________________
gnu-sol-discuss mailing list
gnu-sol-discussopensolaris.org
|
|
| Open Source software and OpenSolaris.
What is the deal? |
|
2007-05-03 23:19:11 |
|
I think the overall issue needs to be broken down into a number of parallel initiatives/projects:
1) There is no common packaging system that meets the needs of the community in use today. We need to come up with one that supports dependencies, updates, and network repositories. (Mirrors are welcome). All parts of Solaris will need to be repackaged with this standard. SFW will be of supported of course, as will unsupported packages. All packages will closely coordinate with Project managers who are OpenSolaris members. Also there is a question as to whether SYSV Package tools can be open sourced. Without that we can't do much with the existing tools, and might have to seriously start thinking about a completely new packaging system. (Initially the GNU stuff would all need to be repackaged, but the end goal would be to have all of Solaris packaged this way.) ; (We need a multi community project to come up with a distributed packaging and build system.) Note to self - It should support self building source packages.
2) There is no common repository for packages. This needs to be addressed. There should be a common repository for OS packages, including the kernel, as well SFW packages, and all the third party and community maintained packages. (Supported or unsupported, this is where people go to get Solaris packages). Sun needs to step up to the plate for this one.
3) If Sun seriously expects third party GNU maintainers to build Solaris packages, they need to provide the build environments, or it just won't happen. Again, Sun really needs to step up.
4) We need to figure out how SFW packages are going to be maintained. I have heard to conflicting visions, both from within Sun. One vision says, stick to a specific version of an Open Source tool, and then just back patch that selfsame version until the next named release of Solaris. The other vision says that if the mainline opensource app has a few verion increments and they warrant updating the SFW package, go ahead and grab the new version and recompile it. We really need to wrap our hands around this, as there is a serious mental divide here. (I actually lean towards a mixed method myself). (This should be hashed out in its own thread, and then a formal should be proposed to the powers that be.)
5) For now, we have to rely on Sun employees, OpenSolaris members and the maintainers from coolwave and sunfreeware.com as our build masters. By consolidating our resources, we should be able to handle more packages. The ideal to become evangelists is a good one, but it's premature. It can't really take off until 1-3 are worked out. I can find GNU maintainers that want to contribute, but they want to just configure compile and bundle their package. They aren't familiar with Solaris, we shouldn9;t force them to become Solaris SAs. Let their contribution be the most efficient it can. The more non package related work we ask them to do the less likely they wil be to get involved. This could be a a future project. I envision that the majority of our package maintainers, will continue to want to maintain packages. There will however, be a new role that package maintainers can opt to take on. That role is integration project manager. That job is to coordinate builds that are being done by other people. This would include unfocused hands that want to help out on either a temporary or ongoing basis, as well as coordinating with authors and GNU package maintainers, that are willing to take on Sun Package maintenance.
6) This is really part of one, but it controversial and will need top level buy in. Whether or not package x is supported or unsupported, it should be installed in the same place. e.g - /usr/bin/x
Ideally once this is all in place, one could run "spm-get upgrade-all" and after some time, the system would be running the latest version of OpenSolaris.
-Brian
|
| Open Source software and OpenSolaris. |
 
United States |
2007-05-04 00:07:42 |
I agree with Mike on his comments and ...
A good portion of the "upstream maintainers" I
have dealt with over the
years either have no Solaris boxes or have either a SPARC or
x86
box, but rarely both, and often NOT running anything like
the most
recent version of Solaris/Opensolaris. If you really want
to avoid
"latency", you will get more of it that you ever
imagined unless you are
willing to ship a lot of free machines, make sure that
developers update
them with the latest Opensolaris releases, and actually do
the work of
getting the packages to the world. Projects like mine and
Dennis's and
whatever potentially replaces the SFW/CCD for Opensolaris
are still the
best bet.
That is not to say the software developers don't want
Solaris packages,
they usually do, but they want someone else to do that.
"Evangelists"
will be needed in a big way to get developers to assist in
porting their
code and promoting its use on Solaris.
This work will likely have to be done by you, the people who
are reading
these discussion lists right now - how much are you willing
to contribute?
As for the CCD latency, since I am now doing the
builds/packaging, here
is the plan. I am currently working to remove the source
packages
builds from the CCD code. Barring any problems, this will
be done very
soon. Then, I (and anyone else who wants to help) will
finish updating
all of the software to the most recent released versions.
New releases
of the CCD package build using the most recent version of
Nevada will be
put on the Opensolaris servers every two weeks (packages for
NV 62 were
put up a few day ago). New versions of the software
contained on the
CCD will be added so long as they build. As programs get
moved to ON or
SFW or elsewhere off of the CCD, they will be removed from
the CCD as
appropriate. All of this is overseen by code reviewers from
companion-discuss and then by submitting RTI's in the usual
way.
It is likely that at some point, the community and Sun will
define some
sort of replacement for the CCD, whether via Laca's project
or something
else. No one should underestimate the amount of resources
any such a
project will take if it is to be successful - whether from
paid
engineers or volunteers.
None of this should affect the projects that supply software
for the
very large group of Solaris 10 or below users where there is
now, and
will continue to be, a big demand. I still have important
users
downloading Solaris 2.5 packages! But, mechanisms for
automating
package builds for Opensolaris that can be made to operate
on older
releases of Solaris could be very useful.
Steve C.
Mike Kupfer wrote:
> I've added companion-discuss to the discussion. And
I've added Laca
> from the JDS group, since he's working on a project[1]
that should make it
> easier to keep third-party apps current. For those
folks: this thread
> was started by Brian Gupta's observation[2] that there
are several
> overlapping projects that deal with third-party open
source code and
> (Open)Solaris and maybe things could be done more
efficiently.
>
>>>>>> "jek3" == Joseph Kowalski
<jek3sun.com> writes:
>
> jek3> I think the concept of CCD is simply bad. We
should not be
> jek3> providing a recompilation and packaging
service. We should be
> jek3> providing assistance to the ultimate code
maintainers to provide
> jek3> Solaris "packages" just like they
provide RPMs (or whatever) for
> jek3> Linux. Let's turn our "recompile"
junkies into "Solaris Packaging
> jek3> Evangelists" (easier said than done -
different skill set - but
> jek3> hopefully you get the idea).
>
> The upstream maintainers will need Solaris boxes (SPARC
and x86) in
> order to produce Solaris packages. I'm skeptical that
they will be
> enthusiastic about this.
>
> jek3> Second, there is an unavoidable latency
introduced by placing a
> jek3> "CCD" service in the loop.
>
> Up through Solaris 10 the Companion had a horrible
latency problem,
> because we only shipped new bits with each Solaris
update release.
>
> Now it has a smaller latency, which is the time to
download the latest
> upstream source, tweak local patches as needed, rebuild
and sanity-test,
> then push new packages to opensolaris.org.
>
> jek3> The Linux distros don't have this latency.
>
> They didn't have the first one that I mentioned, but I
believe they do
> have the second one.
>
> mike
>
> [1] http://mail.opensolaris.org/piperm
ail/companion-discuss/2007-April/000522.html
>
> [2] http://mail.opensolaris.org/pipermail/sf
wnv-discuss/2007-May/000380.html
> _______________________________________________
> companion-discuss mailing list
> companion-discussopensolaris.org
> http://opensolaris.org/mailman/listinfo/companion-discu
ss
>
_______________________________________________
gnu-sol-discuss mailing list
gnu-sol-discussopensolaris.org
|
|
| Open Source software and OpenSolaris.
What is the deal? |
United States |
2007-05-04 20:08:15 |
Mike Kupfer wrote:
> jek3> I think the concept of CCD is simply bad. We
should not be
> jek3> providing a recompilation and packaging
service. We should be
> jek3> providing assistance to the ultimate code
maintainers to provide
> jek3> Solaris "packages" just like they
provide RPMs (or whatever) for
> jek3> Linux. Let's turn our "recompile"
junkies into "Solaris Packaging
> jek3> Evangelists" (easier said than done -
different skill set - but
> jek3> hopefully you get the idea).
>
> The upstream maintainers will need Solaris boxes (SPARC
and x86) in
> order to produce Solaris packages. I'm skeptical that
they will be
> enthusiastic about this.
>
Humm,,...
I'm sending this mail from a fairly small box which can boot
Solaris, 2
flavors
of Windows and 8 (and rising) versions of Linux. I don't
see x86
hardware as
much of an issue.
I understand the sparc issue. Perhaps Sun could do
something useful
with the
"trade-in" boxes we are getting, or something like
that.
One concept discussed was to have a machine farm under
OpenSolaris
auspicies. Probably not as simple as it sounds (to prevent
abuse), but
certainly possible.
> jek3> Second, there is an unavoidable latency
introduced by placing a
> jek3> "CCD" service in the loop.
>
> Up through Solaris 10 the Companion had a horrible
latency problem,
> because we only shipped new bits with each Solaris
update release.
>
> Now it has a smaller latency, which is the time to
download the latest
> upstream source, tweak local patches as needed, rebuild
and sanity-test,
> then push new packages to opensolaris.org.
>
One day beyond it being available for Linux, puts us at a
disadvantage.
> jek3> The Linux distros don't have this latency.
>
> They didn't have the first one that I mentioned, but I
believe they do
> have the second one.
>
I'm not sure what "one" and "two" are
here, but I see I misspoke
anyway. I should
have said "Linux users don't have this latency",
because my point was to
be that they
didn't need to wait for the distro to do anything. Solaris
users don't
have that option.
They can go right to the source...
(and ask the horse...)
- jek3
_______________________________________________
gnu-sol-discuss mailing list
gnu-sol-discussopensolaris.org
|
|
| Open Source software and OpenSolaris.
What is the deal? |
United States |
2007-05-04 21:03:31 |
Laszlo (Laca) Peter wrote:
> On Thu, 2007-05-03 at 19:58 -0700, Mike Kupfer wrote:
>
>> jek3> I think the concept of CCD is simply bad.
We should not be
>> jek3> providing a recompilation and packaging
service. We should be
>> jek3> providing assistance to the ultimate code
maintainers to provide
>> jek3> Solaris "packages" just like
they provide RPMs (or whatever) for
>> jek3> Linux. Let's turn our
"recompile" junkies into "Solaris
>> Packaging
>> jek3> Evangelists" (easier said than done -
different skill set - but
>> jek3> hopefully you get the idea).
>>
>> The upstream maintainers will need Solaris boxes
(SPARC and x86) in
>> order to produce Solaris packages. I'm skeptical
that they will be
>> enthusiastic about this.
>>
>
> Not only that, but if the packages are built and
maintained
> separately, it'll be difficult to find them and will be
unlikely
> to work together. Let's keep in mind that many of the
packages
> we talk about break interfaces in the blink of an eye.
>
> Laca
>
Are you arguing for or against pushing these upstream?
The packages can be build and maintained separately for
Linux. Solaris
has a worse situation because Solaris packaging and testing
happens
after the (release) fact. This is exactly why I want this
pushed upstream.
- jek3
_______________________________________________
gnu-sol-discuss mailing list
gnu-sol-discussopensolaris.org
|
|
| Open Source software and OpenSolaris.
What is the deal? |
|
2007-05-05 04:56:46 |
> > The upstream maintainers will need Solaris boxes
(SPARC and x86) in
> > order to produce Solaris packages. I'm skeptical
that they will be
> > enthusiastic about this.
> >
> Humm,,...
>
> I'm sending this mail from a fairly small box which can
boot Solaris, 2
> flavors
> of Windows and 8 (and rising) versions of Linux. I
don't see x86
> hardware as
> much of an issue.
Yeah it can multiboot. But is that really an ideal way of
working.
Many of the people we are talking about are college
students, without
a huge amount of disposable income. Generally they don't
have a
surplus of hardware, and don't know how to admin Solaris. We
should
not require package maintainers to know how to build a
Solaris
machine. (Not necessarily because it's difficult, but
because it is a
deterant that can easily be removed.) We need to make it
simple for
people to get involved no matter what level of resources
they have.
> I understand the Sparc issue. Perhaps Sun could do
something useful
> with the "trade-in" boxes we are getting, or
something like that.
Maybe, trade in boxes. But I think that LDOMs might be the
way to go.
(From another thread)
> One concept discussed was to have a machine farm under
OpenSolaris
> auspicies. Probably not as simple as it sounds (to
prevent abuse), but
> certainly possible.
I would say that limiting access to those who have signed
contributor
agreements would be a good starting point. (With a strict
abuse
policy.) I would love to hear Dennis' thoughts on abuse, as
he runs a
public build farm.
> I'm not sure what "one" and "two"
are here, but I see I misspoke
> anyway. I should
> have said "Linux users don't have this
latency", because my point was to
> be that they
> didn't need to wait for the distro to do anything.
Solaris users don't
> have that option.
One is the stable version, that ships with Solaris and
doesn't get a
major bump until the next major OS rev. Two is the most
recent
"stable" release, for those people who need
features.
-Brian
_______________________________________________
gnu-sol-discuss mailing list
gnu-sol-discussopensolaris.org
|
|
[1-6]
|
|