Hi,
I created bug 354476 for you to review. Some quick comments would be appreciated. I’ll check-it in with the remaining lucene bundles afterwards and wire it to the feature.
Greetings and have a nice start of the week, Robert
From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Mittwoch, 10. August 2011 21:32
To: Orbit Developer discussion
Subject: Re: [orbit-dev] Proposals for new bundles
> There we have a list of several third party libraries which Skalli
> is using and which are mainly not or only with older versions in the
> orbit currently. Since the CQs took quite a while to get through or
> we didn’t have needs for newer versions, some of the requested
> components do not reflect the most current version.
> 1. How do we deal with such components? Is there a guideline? IMO
> there is quite a high probability that a newer version is released
> during the CQ time.
> We could piggy back on these existing CQs now pretty fast and I
> could create the missing CQs, new branches and projects as needed. I
> would try to follow the “Adding bundles to orbit” guide. Are there
> any objections or additional thoughts?
There's several ways to answer these questions ... but not really sure what you are asking ... so I'll give a several answers, and maybe one of them will match up with your questions.
No, no guidelines, per se. Of course, every addition to Orbit, needs (at least) one Eclipse project to need it, and already have a CQ for that project, then a new Orbit specific CQ needs to be open, to add it to Orbit. (And, those usually go quickly, since already has been reviewed).
Every new release needs a new CQ, but subsequent ones usually go faster than the original, since usually the IP staff are able to look only at "differences". Plus, there are some special parallel IP rules about incremental releases that can speed things up.
In general, if you (or, your project) are the only known user of some third party software, or at least likely to be only user, especially if its "old", as you say, then that'd get the lowest priority for putting into Orbit. The highest priority would be for package that are shared or needed by other Eclipse projects.
> Since this, if agreed, would be my first contribution is there
> someone who could double check what I do in the repo just to make
> sure I don’t go into the wrong direction?
Sure ... well ... I'd suggest you just try it first, asking questions if things seem unclear (so we, or you, can improve the written instructions ... which I know may seem complex to those just getting started). But if/when you really need someone to look, let us know via this mailing list (giving a bugzilla to go with it) and I bet someone would take a look ... and as long as its not during July, I bet it would be a much more timely response that this one!
See http://wiki.eclipse.org/Category:Orbit if you haven't yet.
> Off topic: Are there any plans yet to move to git with the Orbit project?
No, no concrete plans. The topic is (waiting) to be discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=349048
From: "Wetzold, Robert" <robert.wetzold@xxxxxxx>
To: "orbit-dev@xxxxxxxxxxx" <orbit-dev@xxxxxxxxxxx>
Date: 07/06/2011 09:20 AM
Subject: [orbit-dev] Proposals for new bundles
Sent by: orbit-dev-bounces@xxxxxxxxxxx
Hi,
I’m the new guy. Thanks for your votes. I don’t want to bore anyone, so just some very short remarks: I am currently a Java developer working for SAP and very active in the Skalli project. Next to coding I also do lots of infrastructure work like beautifying and keeping Maven builds together, finding p2 repos and providing quality plugins. We are having quite a busy time here so it’s only now that I can start thinking about Orbit contributions. And here we go:
I am referring to the CQs we already have on: http://www.eclipse.org/projects/ip_log.php?projectid=technology.skalli
There we have a list of several third party libraries which Skalli is using and which are mainly not or only with older versions in the orbit currently. Since the CQs took quite a while to get through or we didn’t have needs for newer versions, some of the requested components do not reflect the most current version.
1. How do we deal with such components? Is there a guideline? IMO there is quite a high probability that a newer version is released during the CQ time.
I have prepared a short overview of the components I am talking about. These are all minimum versions required by us, older versions e.g. for lucene do not work as needed (CQ=what was requested and cleared already for us, Out=most current version, Orbit=version in latest R… orbit):
3 CQs: Apache Lucene Core, Highlighter, Queries 3.0.2
Out: 3.3
Orbit: 2.9.1
CQ: xstream 1.3.1
Out: 1.3.1
Orbit: none
3 CQs: Restlet API, Servlet Extension, XStream Extension 2.0.5
Out: 2.0.8
Orbit: none
CQ: XMLUnit 1.2
Out: 1.3
Orbit: none
CQ: xmlpull 1.1.3.4b
Out: 1.1.3.4c
Orbit: none
2. We could piggy back on these existing CQs now pretty fast and I could create the missing CQs, new branches and projects as needed. I would try to follow the “Adding bundles to orbit” guide. Are there any objections or additional thoughts?
3. Since this, if agreed, would be my first contribution is there someone who could double check what I do in the repo just to make sure I don’t go into the wrong direction?
Greetings, Robert
4. Off topic: Are there any plans yet to move to git with the Orbit project?
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
