Community
Participate
Working Groups
It would be useful to have a new kind of CQ for "put in Orbit". This new CQ requests the ipbug# of the original contribution and the destination directory and version number in the Orbit CVS. Once the bug is approved, the project could then place the bundle in orbit.
Adjusting priority to reflect importance for Ganymede.
Per conversation with Janet: use "[move] a previously approved third-party library to Orbit" See also bug 220422
Coded and checked-in. Will go live in next roll to production.
I don't have the option to reopen this bug, Bjorn. Further to our email communication earlier this afternoon, could you please reopen it? Thanks in advance. We've had some experience with this feature now, and can provide some feedback to further clarify the requirement. In essence, this is a special "piggyback" function for Orbit. The differentiator for CQs piggybacked to Orbit (versus CQs piggybacked elsewhere) is a mandatory requirement that the Orbit committer enter in the CQ (a) the destination directory and (b) version number in the Orbit CVS. Is it possible to introduce this requirement for Orbit CQs? Having said that, the term "move" appears to give some committers the impression that they are losing the rights to distribute the package from the project that originated that CQ, because it and all it's inherent rights appear to be "moving" to Orbit. Could we change the term "move to Orbit" to either "piggyback to Orbit" or "add to Orbit"? Here is a scenario that we hope will provide further clarification: Orbit committer wants to offer a bundle in Orbit. Orbit committer creates a new CQ by "piggybacking" or "adding" it to Orbit from a previously approved CQ. The new CQ is automatically populated with ALL the info from the old CQ except: a) committer name is the new Orbit committer b) project is orbit c) keywords are not auto-populated, rather the Orbit committer is prompted with the same set of questions as would be posed on the original request that served to generate the keywords (mandatory) d) much the same as regular piggybacked CQs, the summary would be an exact replica of the originating CQ with the following appended in parenthesis at the end: "PBO CQ9999" or "ATO CQ9999" (depending upon whether you think "Piggyback to Orbit" or "Add to Orbit" is clearer) Please let me know if further clarification is required. Thanks Bjorn. Cheers, Barb
Re-opening bug. See comment #4.
(In reply to comment #4) > I don't have the option to reopen this bug "User has been updated" - you do now :-) > is a mandatory requirement that the Orbit committer enter in the CQ (a) the > destination directory and (b) version number in the Orbit CVS. Can you (a) give me the wording for the prompts and (b) explain how the process is going work? I'm not entirely clear here, so I hesitate to invent something. For instance: the "version number in the Orbit CVS" - do you mean the CVS revision number of the file itself? Because that can't be known until the file is committed, which can't happen until after the CQ is approved. So I must be missing something... > a) committer name is the new Orbit committer > b) project is orbit a,b - ok > c) the Orbit committer is prompted with the same set of questions as would be posed on the original request that served Uh... why? Isn't that just extra work for the committer? Is there any reason to believe that the set of keywords is going to change? Why would we ask for them to enter the information again if we have the information once? > d) much the same as regular piggybacked CQs d - ok > Please let me know if further clarification is required. See this comment :-)
(In reply to comment #6) > (In reply to comment #4) > > > is a mandatory requirement that the Orbit committer enter in the CQ (a) the > > destination directory and (b) version number in the Orbit CVS. > > Can you (a) give me the wording for the prompts and (b) explain how the process > is going work? I'm not entirely clear here, so I hesitate to invent something. > For instance: the "version number in the Orbit CVS" - do you mean the CVS > revision number of the file itself? Because that can't be known until the file > is committed, which can't happen until after the CQ is approved. So I must be > missing something... > Hmmm - I would welcome feedback with regard to nomenclature and timing. Essentially, from this URL [http://download.eclipse.org/tools/orbit/downloads/], we would like to know in which build name, and then within that build name, within which individual bundle [name and version number] the third party package that is the subject of the CQ is either (a) already included or (b) is targeted for inclusion (if not there yet). Re (a) already included: In many cases, the third party packages are already in Orbit so the destination is known and should be easy to capture. There is an exercise afoot to get CQs into IPZilla to reflect that reality. Re (b) targeted for inclusion: Going forward, we would expect scenario (b) to prevail. Bearing in mind that CQs that are piggybacked to Orbit are typically processed very quickly (hours / days), is it unrealistic to think that committers can predict the target bundle where the third party package will reside? > > > c) the Orbit committer is prompted with the same set of questions as would be posed on the original request that served > > Uh... why? Isn't that just extra work for the committer? Is there any reason to > believe that the set of keywords is going to change? Why would we ask for them > to enter the information again if we have the information once? > Perhaps I jumped the gun on this one :-). Let me ask a question in response to yours in order to seek a resolution. Is there a possibility that the use of a third party package in Orbit would be different than the originating project's use of that same third party package?
(In reply to comment #4) > Could we change the term "move to Orbit" to "add to Orbit"? Done. > a) committer name is the new Orbit committer The committer name is the person opening the CQ. > b) project is orbit Changed. Now the originating project is not mentioned in the CQ at all, but I guess you can find it from the piggybacked CQ. > d) the summary would be an exact > replica of the originating CQ + "ATO CQ9999" Done. I have not done anything vis a vis (c) - when you figure out what you want, go ahead and reopen this bug.
I do not believe I have the capability to "Reopen" this bug either:-( We have received a request from the community for ATO CQs to include a link to the original Approved CQ. I believe the PB CQs contain this link in the description area of the CQ so it would make sense to do the same on the ATOs. Thanks, Sharon
reopen for Sharon
Add the piggyback reference to the description.
