[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: AW: [equinox-dev] Equinox->Bundles component is getting crowded
|
I agree that tagging is a better solution than (always arbitrary)
hierarchies. Over time, I have learned that any hierarchy is always
wrong for some people. Flickr shows how people can create their own
groups by including a set of tags and I think it is highly successful.
Or look at SQL, invented to solve the problem of hierarchical (or
networked) databases that always turned out to have the wrong
hierarchy for any new application.
You can always create "groups" by searching for tags or create tracks
like they use on EclipseCon to create mini-programs.
In the OSGi, we have the Bundle-Category header that has a set of
defined values. We gladly adjust this list.
http://www2.osgi.org/Specifications/Reference
Kind regards,
Peter Kriensa
AvD> I was primarily thinking about web pages for downloading and searching
AvD> bundles. A download page which would show all server side bundles would
AvD> have some items that are also on the standard bundles page. It doesn't
AvD> solve the problem of what each downloadable item should comprise and it
AvD> doesn't help with tools like bugzilla or how to address things on the
AvD> mailing lists. Personally I would tend to make the items small when
AvD> tagging is available, e.g. a download per bundle. I'd do the same on the
AvD> bugzilla side with rather fine grained partitioning.
AvD> The download pages could even offer you to choose several
AvD> tags/categories to include in your download and then pack you an
AvD> individual downloadable bundles archive without duplicates and all the
AvD> items you wanted. (Ah, the lovely smell of over-engineering in the early
AvD> morning :) ).
AvD> Arthur
AvD> Jeff McAffer wrote:
>>
>> can you say more about the mechanism for "tagging"? The sorts of
>> media/item in question are downloads, bundles in the repo, wiki/web
>> information, posts on the mail list or newsgroup, bugs, ... Not all
>> need the same level of rigor perhaps.
>>
>> Jeff
>>
>>
>>
>> *"Arthur van Dorp" <Arthur.vanDorp@xxxxxxxxx>*
>> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>>
>> 09/14/2007 01:20 AM
>> Please respond to
>> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>>
>>
>>
>> To
>> "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
>> cc
>>
>> Subject
>> AW: [equinox-dev] Equinox->Bundles component is getting crowded
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > 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"?
>>
>> As an outsider I'd say use tags. HttpService would be tagged
AvD> "standard"
>> as well as "server side". That would naturally involve some work on
AvD> both
>> front and back end and not in itself guarantee that people would
AvD> easily
>> find what they are looking for.
>>
>> Arthur
>>
>> Jeff McAffer wrote:
>> >
>> > 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
AvD> 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
AvD> one
>> > from the other. Since there is no particular web/wiki page for
AvD> 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
AvD> 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
AvD> 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
AvD> 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
AvD> 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
AvD> 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
AvD> be
>> > managed by groups and groups will have a 1:1 relationship to
>> components
>> > and components will have associated leads, bugzilla entries,
AvD> 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.
AvD> Our
>> > solution space seem to be N bundles => 1 group, N groups or M
AvD> 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
AvD> 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
AvD> as
>> > security or provisioning), but isn't interested in the rest of the
>> > framework, they could quickly earn commit rights in that area,
AvD> without
>> > having to give them write access to other code they aren't
AvD> qualified
>> to
>> > maintain (or aren't interested in maintaining). On the question of
>> > bugzilla components, I don't particularly care whether we have one
AvD> 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,
AvD> 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
AvD> EMO
>> has
>> > a plan under consideration for standardizing the group structure
AvD> 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).
AvD> Essentially,
>> > simultaneously nominating an individual for N groups would only
>> require a
>> > single election, and a single vote per committer. Just some things
AvD> 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
AvD> bundle
>> > individually so each bundle is a separate downloadable item.
AvD> Creating
>> a
>> > separate component for each and every bundle in Equinox may prove
AvD> 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
AvD> 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
AvD> need
>> :-)
>> >
>> > I think we a balance and create components as we see fit to split
AvD> 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
AvD> 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
AvD> other
>> > security related work that will not really fit into any one
AvD> component.
>> >
>> > Tom
>> >
>> >
>> >
>> > John Arthorne ---09/12/2007 11:25:42 AM---Creating a new component
AvD> 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
AvD> don't
>> know
>> >
>> > much about the security work, but that may be difficult to
AvD> partition
>> into
>> > its own component because it's an inherently cross-cutting concern.
AvD> If
>> > there end up being a number of security-specific bundles, it may
AvD> 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
AvD> 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
AvD> "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
AvD> the
>> work
>> > which is graduated into Equinox? I think the p2 and security work
AvD> 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
>> >
>> >
>> >
>>
AvD> ------------------------------------------------------------------------
>> >
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
AvD> _______________________________________________
AvD> equinox-dev mailing list
AvD> equinox-dev@xxxxxxxxxxx
AvD> https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
