[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Equinox->Bundles component is getting crowded
|
to me it is neither of these options.
It is about community and clarity for our consumers. Walking
up to Equinox you just have a sea of bundles. Add in the p2 and security
stuff and the sea turns into an ocean. Say you hear that Equinox
has implementations of some OSGi service specs. If you go to the
download page today you have to grovel through spec impls, launchers, random
other stuff and cannot tell one from the other. Since there is no
particular web/wiki page for people interested in spec implementations,
it is hard to build a community around that topic. People interested
in contributing to standard spec impls cannot easily find related bugs
etc. There is also no clear lead of that community who is plotting
the course/planning, coordinating execution, building the community, ...
You can replace OSGi service spec with p2, security, ...
A number of these issues can be addressed
simply by structuring the download site or wiki or... If you address
most of them then in effect you have just created a component without actually
creating a component. So what are we afraid of? Why not reify
the structure we think we have?
That begs the question, what is the
structure? The challenge is that all partitionings will have problems as
different people have different views on the world. would the http
service be part of "standard services" or "server side"?
However the existance of issues need not stop progress or movement.
So this discussion is really about defining that structure. At
least thats my view...
Jeff
BJ Hargrave <hargrave@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
09/12/2007 05:13 PM
|
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> |
|
|
To
| Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| Re: [equinox-dev] Equinox->Bundles
component is getting crowded |
|
What is the point of the proposed change? Tom's
mail suggests we
subdivide bundles. But in what way? To organize commit rights or bugs in
bugzilla? Or both? I guess that is what is not clear. Clarity here will
help us evaluate choices. It seems we can easily have M bugzilla
components and N commit right sets with M >=N. Right now (for bundles)
M
and N both equal 1. Are we looking to increase M or N or both?
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx
office: +1 386 848 1781
mobile: +1 386 848 3788
From:
Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
To:
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:
2007-09-12 16:03
Subject:
Re: [equinox-dev] Equinox->Bundles component is getting crowded
yes but under the new plan you pointed out, the commit rights will be
managed by groups and groups will have a 1:1 relationship to components
and components will have associated leads, bugzilla entries, websites,
...
This is alot of infrastructure to put in place for each bundle.
We did "bundles" originally because we could not come up with
any
reasonable partitioning of the space. To date we have gotten away
with it
because a) the number of bundles in there was relatively low and b) many
have very little activity. As Tom points out, this is changing. Our
solution space seem to be N bundles => 1 group, N groups or M groups
where
1 < M < N. Unfortunately, it is still not clear that there
is a
reasonable grouping so while (at least to me) M groups feels like a good
spot, it will be challenging. Here are some thoughts
- "framework" = the framework. This stays unchanged
- "standard" = bundles that implement OSGi standard services
- "p2"
- "security" = if needed
- "bundles" = catch all for things that don't fit
This is just a stake in the ground.
Jeff
John Arthorne/Ottawa/IBM@IBMCA
Sent by: equinox-dev-bounces@xxxxxxxxxxx
09/12/2007 03:42 PM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: [equinox-dev] Equinox->Bundles component is getting crowded
Since "component" is a confusing term, I should clarify my comments
on
this. I like the idea of being more fine-grained with Unix groups
(CVS
commit rights), because I think it encourages new committers. If someone
joins the community with a strong interest in a narrow area (such as
security or provisioning), but isn't interested in the rest of the
framework, they could quickly earn commit rights in that area, without
having to give them write access to other code they aren't qualified to
maintain (or aren't interested in maintaining). On the question of
bugzilla components, I don't particularly care whether we have one or ten
- these are fairly easy to change over time as the need arises.
John
John Arthorne/Ottawa/IBM@IBMCA
Sent by: equinox-dev-bounces@xxxxxxxxxxx
09/12/2007 03:24 PM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: [equinox-dev] Equinox->Bundles component is getting crowded
I agree one component per bundle is probably overkill. However, it's
not
necessarily true that the CVS commit groups match 1-1 with Bugzilla
groups. While it's often convenient to do it this way, it's not a
constraint that we need to conform to. I should also add that the
EMO has
a plan under consideration for standardizing the group structure for Unix
groups, and part of this work is to facilitate election across multiple
groups (see item 6 in
https://bugs.eclipse.org/bugs/attachment.cgi?id=77092). Essentially,
simultaneously nominating an individual for N groups would only require
a
single election, and a single vote per committer. Just some things to
consider...
Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
09/12/2007 02:47 PM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: [equinox-dev] Equinox->Bundles component is getting crowded
There are two extreme positions to take. Lump a large number of loosely
related deliverables under one component or create a separate component
for each and every deliverable. I'm not sure I favor the latter extreme.
Currently the Equinox download page allows you to download each bundle
individually so each bundle is a separate downloadable item. Creating a
separate component for each and every bundle in Equinox may prove to be
too much overhead. It is my understanding that in Eclipse typically every
bugzilla component has its own set of commit rights in CVS. If we have
a
very high number of components then we will be holding a very large number
of committer elections to get all the committers the access they need :-)
I think we a balance and create components as we see fit to split up the
different work areas in Equinox instead of creating a component for every
bundle.
Tom
BJ Hargrave---09/12/2007 12:31:35 PM---It would probably be best if each
separately downloadable item had its own
BJ Hargrave/Austin/IBM@IBMUS
Sent by: equinox-dev-bounces@xxxxxxxxxxx
09/12/2007 12:30 PM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: [equinox-dev] Equinox->Bundles component is getting crowded
It would probably be best if each separately downloadable item had its
own
component against which people could file bugs.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx
office: +1 386 848 1781
mobile: +1 386 848 3788
From:
Thomas Watson/Austin/IBM@IBMUS
To:
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:
2007-09-12 12:34
Subject:
Re: [equinox-dev] Equinox->Bundles component is getting crowded
For the security stuff I was referring to the security-specific bundles
like login (JAAS integration etc.)
You are right there is a lot of cross-cutting concerns with the other
security related work that will not really fit into any one component.
Tom
John Arthorne ---09/12/2007 11:25:42 AM---Creating a new component for
p2
definitely makes sense to me. I don't know much about the security work,
but that may be diffi
John Arthorne <John_Arthorne@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
09/12/2007 11:21 AM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
Re: [equinox-dev] Equinox->Bundles component is getting crowded
Creating a new component for p2 definitely makes sense to me. I don't know
much about the security work, but that may be difficult to partition into
its own component because it's an inherently cross-cutting concern. If
there end up being a number of security-specific bundles, it may make
sense.
Generally speaking, I think more components is a good thing. It's a great
way to bring in new committers who may not be able to make the large
commitment needed to contribute across a large part of Equinox.
John
Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
09/12/2007 11:42 AM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
To
equinox-dev@xxxxxxxxxxx
cc
Subject
[equinox-dev] Equinox->Bundles component is getting crowded
The Equinox project continues to grow with new components and new
contributes being added. Thanks everyone!!
As new contributions are graduated into Equinox proper we need to place
them under one of the existing components. Currently we have the
"Framework" and "Bundles" components for Equinox proper
in bugzilla/cvs. A
large majority of the new contributions will fall into the "Bundles"
component. For example, we have a few work areas in the equinox incubator
which are very active (e.g. p2, security etc). Once this work graduates
it
will likely to be placed into the generic "Bundles" component.
This will
make an already crowded component even more crowded.
Should we consider creating a more diverse set of components for the work
which is graduated into Equinox? I think the p2 and security work will
deserve their own component when they graduate. Thoughts?
Tom
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
(See attached file: pic01850.gif)
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Attachment:
pic01850.gif
Description: GIF image
