Community
Participate
Working Groups
The 'proctools' component needs to be migrated from Sequoyah to Linux Tools project. Component feature and plugins: - features org.eclipse.sequoyah.device.linuxtools.feature - plugins org.eclipse.sequoyah.device.linuxtools org.eclipse.sequoyah.device.linuxtools.base Bugs related to this component and that need to be migrated: 258557, 258556, 255255, 243498, 243497, 243496, 243225 CQs related to this component and that need to be migrated: 2996, 3065, 3066, 3376
CQs as identified have been moved to Tech Linux Tools Project. Please note as per the Review Process; committers cannot be moved along with code into an existing project. In this case, the existing project must elect the new committers into the project. Over to Webmaster.... Thanks, Sharon
So for me to preform an actual 'move' will require I take both repositories offline, dump,filter and reload Sequoyah and then import into Linuxtools. When is a good time for the projects? -M.
(In reply to comment #2) For Sequoyah, the best time would be after Helios SR1 (September 24). Tks, Marcel > So for me to preform an actual 'move' will require I take both repositories > offline, dump,filter and reload Sequoyah and then import into Linuxtools. > > When is a good time for the projects? > > -M.
I've added the PL's for Linux tools so we can sort out when to do this move. -M.
Where are we in terms of timing for this move? Where is this component moving 'to'(ie: /svnroot/technology/org.eclipse.linuxtools/some/place )? -M.
(In reply to comment #5) From Sequoyah side, it can occur anytime now (since SR1 has already been released). > Where are we in terms of timing for this move? > > Where is this component moving 'to'(ie: > /svnroot/technology/org.eclipse.linuxtools/some/place )? > > -M.
(In reply to comment #5) > Where are we in terms of timing for this move? > > Where is this component moving 'to'(ie: > /svnroot/technology/org.eclipse.linuxtools/some/place )? > > -M. The naming structure is: /svnroot/technology/org.eclipse.linuxtools/subprojectname/[trunk, branches, tags] For this project, "proctools" would be fine for the subprojectname. Underneath this structure are the plugins and features which are prefixed with org.eclipse.linuxtools. Features are typically suffixed with -feature in their names (e.g. org.eclipse.linuxtools.cdt.autotools-feature)
Ok I'd like to schedule this move for next wednesday(Oct. 27th). Is that a problem? -M.
(In reply to comment #8) > Ok I'd like to schedule this move for next wednesday(Oct. 27th). Is that a > problem? > > -M. Fine by me.
(In reply to comment #9) It's ok for Sequoyah too. > (In reply to comment #8) > > Ok I'd like to schedule this move for next wednesday(Oct. 27th). Is that a > > problem? > > > > -M. > > Fine by me.
Ok, I've loaded the Sequoyah data into the Linuxtools repo. Please let me know if something is missing/wrong. I"m working on filtering the data out of the Seqouyah repo but it's proving problematic. It may be faster for the Seqouyah team to remove it. -M.
(In reply to comment #11) > Ok, I've loaded the Sequoyah data into the Linuxtools repo. Please let me know > if something is missing/wrong. > > I"m working on filtering the data out of the Seqouyah repo but it's proving > problematic. It may be faster for the Seqouyah team to remove it. > > -M. Done! Removed from trunk@2324. Please let us know if there's something else we should do. Thanks, Daniel Pastore Sequoyah Team
My only other question is which component (in Linuxtools) should the bugs move to? -M.
(In reply to comment #12) > (In reply to comment #11) > > Ok, I've loaded the Sequoyah data into the Linuxtools repo. Please let me know > > if something is missing/wrong. > > > > I"m working on filtering the data out of the Seqouyah repo but it's proving > > problematic. It may be faster for the Seqouyah team to remove it. > > > > -M. > Done! > > Removed from trunk@2324. > > Please let us know if there's something else we should do. > > Thanks, > > Daniel Pastore > Sequoyah Team Just noticing the new files. From the Eclipse naming conventions, the plugin and feature names need to be renamed to start with: org.eclipse.linuxtools where linuxtools is the subproject name http://wiki.eclipse.org/Naming_Conventions ============================================================================ The first package name segment after org.eclipse is generally the subproject name, followed by the component name. org.eclipse.<subproject>.<component>[.*]- General form of package names ============================================================================ Please also see: http://wiki.eclipse.org/Linux_Tools_Project/Releng#Adding_a_new_component You are missing the tags folder. There is information there on how to get your component into the build. We generally don't have a plugins and features folder and just have our feature names end with -feature to distinguish. This isn't a rule as of yet as the map file should handle any differences like this anyway.
(In reply to comment #13) > My only other question is which component (in Linuxtools) should the bugs move > to? > > -M. A new component: proctools is required. I don't know if I can do this in Andrew's absence. Can you set this up?
(In reply to comment #15) > A new component: proctools is required. I don't know if I can do this in > Andrew's absence. Can you set this up? Sure, who should be the default owner? (In reply to comment #14) > Just noticing the new files. From the Eclipse naming conventions, the plugin > and feature names need to be renamed to start with: > > org.eclipse.linuxtools where linuxtools is the subproject name > > http://wiki.eclipse.org/Naming_Conventions > ============================================================================ > The first package name segment after org.eclipse is generally the subproject > name, followed by the component name. > > org.eclipse.<subproject>.<component>[.*]- General form of package names > ============================================================================ > > Please also see: > > http://wiki.eclipse.org/Linux_Tools_Project/Releng#Adding_a_new_component > > You are missing the tags folder. There is information there on how to get your > component into the build. > > We generally don't have a plugins and features folder and just have our feature > names end with -feature to distinguish. This isn't a rule as of yet as the map > file should handle any differences like this anyway. So how would you like to solve these? The fastest solution is probably for you(or another Linuxtools dev) to move things where you expect them to be. I can try and re-work the the dumps and the repository to cause these changes but at the cost of losing any committs since the data was added, and possibly the 'integrity' of the repo itself. -M.
(In reply to comment #16) > (In reply to comment #15) > > > A new component: proctools is required. I don't know if I can do this in > > Andrew's absence. Can you set this up? > > Sure, who should be the default owner? > If it can be Marcel, then make it him. Otherwise, assign to me for the time-being. > (In reply to comment #14) > > Just noticing the new files. From the Eclipse naming conventions, the plugin > > and feature names need to be renamed to start with: > > > > org.eclipse.linuxtools where linuxtools is the subproject name > > > > http://wiki.eclipse.org/Naming_Conventions > > ============================================================================ > > The first package name segment after org.eclipse is generally the subproject > > name, followed by the component name. > > > > org.eclipse.<subproject>.<component>[.*]- General form of package names > > ============================================================================ > > > > Please also see: > > > > http://wiki.eclipse.org/Linux_Tools_Project/Releng#Adding_a_new_component > > > > You are missing the tags folder. There is information there on how to get your > > component into the build. > > > > We generally don't have a plugins and features folder and just have our feature > > names end with -feature to distinguish. This isn't a rule as of yet as the map > > file should handle any differences like this anyway. > > So how would you like to solve these? The fastest solution is probably for > you(or another Linuxtools dev) to move things where you expect them to be. I > can try and re-work the the dumps and the repository to cause these changes but > at the cost of losing any committs since the data was added, and possibly the > 'integrity' of the repo itself. > > -M. Ok, we'll handle it one way or another.
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > > > A new component: proctools is required. I don't know if I can do this in > > > Andrew's absence. Can you set this up? > > > > Sure, who should be the default owner? > > > > If it can be Marcel, then make it him. Otherwise, assign to me for the > time-being. Shouldn't the owner be someone from Linux Tools project? :)
Ok, I've created the component, made Jeff the owner and moved the bugs. -M.
Move finished.
I should perhaps note here that Linux Tools is not shipping proctools in our Indigo contribution.
(In reply to comment #21) > I should perhaps note here that Linux Tools is not shipping proctools in our > Indigo contribution. Hi Andrew, from Sequoyah side, there's no problem at all. The component is now yours, so use it whenever you feel you are ready. :) Thanks, Daniel Pastore
