Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #487542 +++ The heart of this proposal is to move the "b3 aggregator" to CBI. This seems logical, since while it may have some "outside" users, it is primarily used for our yearly Simultaneous Release, AFAIK. My motivation is to give that aggregator a more visible, central home to both make it easier to maintain and encourage contributions. One issue is what to do with the "beelang" modules. As far as I know, the "b-language" effort stopped long ago. I propose to "move them" with the aggregator modules, for simplicity, but then they would soon be removed from 'master' in their CBI home. In effect, this would "archive" the b3 project. I am open to suggestions! I do have a "draft" of a Tycho build running (see bug 487478) and think I have identified the main modules that make up the b3 aggregator editor. I am opening this bug for discussion, and eventually, will document the concrete steps needed to make "the move". Typically when a project like this moves to another project, all the committers also move to the new project. I am very open to suggestions on this point, but since the existing committers have all been very inactive, for a very long time, I suggest they not move automatically. Of course, if any of them say they do want to keep commit rights, that is fine with me. Similarly, if, in the future, an existing committer wants to work on it again, I am sure they could be voted into CBI relatively easily. Suggestions welcome. I would expect that things like package names (for the aggregator related bundles) would change to contain 'cbi' instead of 'b3'. Comments?
Thanks David for this proposals. A big +1 on this for all the reasons you mentioned. Making the checks also usable from Tycho is IMHO a very good direction to take.
I also like the idea. (In reply to David Williams from comment #0) > One issue is what to do with the "beelang" modules. As far as I know, the > "b-language" effort stopped long ago. I propose to "move them" with the > aggregator modules, for simplicity, but then they would soon be removed from > 'master' in their CBI home. I'm not familiar with these modules. If the effort stopped long ago, your suggestion seems fair enough: let's move them to the cbi repo, and remove them from the master branch as soon as the move is completed. > In effect, this would "archive" the b3 project. I am open to suggestions! Regarding the archival of the b3 project, did you talk with the current project leader? I'm not familiar with the process if they are not responding anymore. > I do have a "draft" of a Tycho build running (see bug 487478) and think I > have identified the main modules that make up the b3 aggregator editor. Terrific > I am opening this bug for discussion, and eventually, will document the > concrete steps needed to make "the move". > > Typically when a project like this moves to another project, all the > committers also move to the new project. I am very open to suggestions on > this point, but since the existing committers have all been very inactive, > for a very long time, I suggest they not move automatically. Of course, if > any of them say they do want to keep commit rights, that is fine with me. > Similarly, if, in the future, an existing committer wants to work on it > again, I am sure they could be voted into CBI relatively easily. Suggestions > welcome. Agreed on not moving incative committers from b3 to cbi except if they actively said they want to continue contributing. > I would expect that things like package names (for the aggregator related > bundles) would change to contain 'cbi' instead of 'b3'. package / bundle names should be rename from b3 to cbi, right.
(In reply to Mikael Barbero from comment #2) > Regarding the archival of the b3 project, did you talk with the current > project leader? I'm not familiar with the process if they are not > responding anymore. I did not talk directly about archiving -- just the move -- but in bug 487542 comment 1 Henrik (project lead) says we can. > > I would expect that things like package names (for the aggregator related > > bundles) would change to contain 'cbi' instead of 'b3'. > > package / bundle names should be rename from b3 to cbi, right. Yes. (Thought that was what I said :)
(In reply to David Williams from comment #3) > (In reply to Mikael Barbero from comment #2) > > > Regarding the archival of the b3 project, did you talk with the current > > project leader? I'm not familiar with the process if they are not > > responding anymore. > > I did not talk directly about archiving -- just the move -- but in bug > 487542 comment 1 Henrik (project lead) says we can. Ok, sorry for the misunderstanding. > > > > > I would expect that things like package names (for the aggregator related > > > bundles) would change to contain 'cbi' instead of 'b3'. > > > > package / bundle names should be rename from b3 to cbi, right. > > Yes. (Thought that was what I said :) Indeed, I was just trying to (poorly) say that I agree :)
The review process has formally started and all basic approval obtained. Assuming no objections from the community, the review will conclude on March 2. That will be the approximate date I would want to start "moving stuff", so thought I would start the discussion now. Bugzilla: I am thinking the component name should be something like CBI p2 Repository Aggregator? or, I guess since in the CBI "product" that p2 Repository Aggregator would suffice ... making it very similar to the 'p2 Repository Analyzers" we just added. (Which, I think is good). Git: I guess we should continue the parallelism and make the new repository org.eclipse.cbi.p2repo.aggregator.git The bundle names and packages would follow that same pattern. Examples: org.eclipse.b3.aggregator ==> org.eclipse.cbi.p2repo.aggregator org.eclipse.b3.aggregator.edit ==> org.eclipse.cbi.p2repo.aggregator.edit There are some packages that do not have "aggregator" in them currently, I suggest we add it, unless it conflicts with another. For example, org.eclipse.b3.p2.maven ==> org.eclipse.cbi.p2rep.aggregator.maven One "catch" is I am not sure how this effects (or, is affected by, the EMF models that are part of the project. I will need to investigate that. Wiki: There is already a "top level" page for CBI: https://wiki.eclipse.org/CBI I guess best to follow the namespace in setting up pages. For example, have a https://wiki.eclipse.org/CBI/p2repo/aggegator And then existing "b3" pages related to the aggregator would move under that, such as https://wiki.eclipse.org/Eclipse_b3/aggregator/manual would be moved (renamed) to https://wiki.eclipse.org/CBI/p2repo/aggegator/manual Comments on exact names or ommissions welcome.
I'm afraid that changing packages could introduce some confusion. Indeed, even if packages change, the EMF namespaces should change, and it's usually simpler to keep them in sync. As a tentative contributor to b3, I fail at identifying the value of refactoring the bundles. I would suggest to first complete the "tactical" migration to CBI without changing the code nor bundle names; and then discuss the necessity and benefits of refactoring names on a separate bug.
(In reply to Mickael Istria from comment #6) > I'm afraid that changing packages could introduce some confusion. Indeed, > even if packages change, the EMF namespaces should change, and it's usually > simpler to keep them in sync. > > As a tentative contributor to b3, I fail at identifying the value of > refactoring the bundles. > I would suggest to first complete the "tactical" migration to CBI without > changing the code nor bundle names; and then discuss the necessity and > benefits of refactoring names on a separate bug. I have opened bug 488181 per your request.
From a contributor POV, what seems to matter the most is Gerrit, to more easily share reviews and ongoing work. Can we expect the Gerrit for b3 at CBI soon?
(In reply to Mickael Istria from comment #8) > From a contributor POV, what seems to matter the most is Gerrit, to more > easily share reviews and ongoing work. Can we expect the Gerrit for b3 at > CBI soon? Yes, very soon. By mid-March or so. (Assuming the transfer happens officially on March 2, then to allow some time to get the build running and do the renaming that I want to do.)
The formal review was officially approved today (bug 487968). So ... if Mikael or webmaster can create a new repo under "CBI" I think I can take it from there. Well, guess I could create one? But, was hoping for "creation and initial content", as we did for the 'simrel tests" one. The new repo is to be named org.eclipse.cbi.p2repo.aggregator.git and it's initial contents would be the whole repo at /gitroot/b3/b3.git I am not sure I have authority to do a clone --bare to the new location, and at any rate we would like the new one set up to accept commits through a "Gerrit URL", BUT, I will want the ability to push directly to /refs/heads/<branch> (in addition to /refs/for/<branch> Sound ok? Once that is done, I can delete (from master) those projects we do not plan to use (beelang related) and work on the renaming and the build of the others. I think I can handle the bugzilla component and "moving" of bugs myself, as well as the wiki pages.
I've created the repo https://git.eclipse.org/r/#/admin/projects/cbi/org.eclipse.cbi.p2repo.aggregator. It is gerrit-enabled and all CBI's committers can bypass Gerrit (ie push to refs/heads).
(btw the repo is a clone --bare of /gitroot/b3/b3.git so the history is exactly the same: http://git.eclipse.org/c/cbi/org.eclipse.cbi.p2repo.aggregator.git/)
Would be nice to have a snapshot build of B3 whenever master change, and to have a job to verify incoming patches via Gerrit. Is this something I can help to set up?
(In reply to Mickael Istria from comment #13) > Would be nice to have a snapshot build of B3 whenever master change, and to > have a job to verify incoming patches via Gerrit. Is this something I can > help to set up? No thanks. Not at thsi time.
(In reply to David Williams from comment #5) > Bugzilla: I am thinking the component name should be something like > CBI p2 Repository Aggregator? I have created the new bugzilla component named "CBI p2 Repository Aggregator". (I decided it would be good to repeat "CBI" since I believe this will become known as the "CBI aggregator", so I think easier to find the right component).
(In reply to David Williams from comment #15) > I have created the new bugzilla component named "CBI p2 Repository > Aggregator". I tested moving 3 bugs from "EMFT.b3" to here, and did see that it sent out a "notice" for each one of them. Since there is nearly 300 bugs there I would like to move here, I will ask webmasters if they can easily "turn off" notifications for those bugs. If not, I will at least give warning and allow people to "unsubscribe" if they want to avoid giving so many notices.
(In reply to David Williams from comment #16) > (In reply to David Williams from comment #15) > > I have created the new bugzilla component named "CBI p2 Repository > > Aggregator". > > I tested moving 3 bugs from "EMFT.b3" to here, and did see that it sent out > a "notice" for each one of them. Since there is nearly 300 bugs there I > would like to move here, I will ask webmasters if they can easily "turn off" > notifications for those bugs. If not, I will at least give warning and allow > people to "unsubscribe" if they want to avoid giving so many notices. After some email discussion with one of the webmasters, it seems easiest just to do this with out "turning off" notification (it has to be turned off for *all* bugzilla notices, which does not seem worth while or fair; and, in honestly, for some "subscribed" to an important bug, seeing it "move" might be important information to them). But, I will send notice to cbi-dev list and b3-dev list in case anyone wants to adjust their bugzilla settings. I will plan on doing this between 3 and 5 PM (Eastern) on Friday 9/16. I anticipate doing it in several "waves" and in some cases there will might be more than one notice per bug.
(In reply to David Williams from comment #17) > ... > > I will plan on doing this between 3 and 5 PM (Eastern) on Friday 9/16. I > anticipate doing it in several "waves" and in some cases there will might be > more than one notice per bug. I have completed moving bugs from EMFT.b3. I moved bugs from the components "aggregator", "Editor", and "meta". But did not move any from the component named "engine" as that was for only the "b3 builder" as far as I can tell. = = = = = = So, webmaster, if you would like to put "EMFT.b3" bugzilla product in "read only" mode, that would be fine with me. = = = = = = Before EMFT.b3 is completely terminated or archived, though, I still need to look at and move some wiki pages, and probably copy some downloads or update sites, and _maybe_ some webpages.
The only "aggregator" item I could find on the b3 wiki was the "manual", which I have now moved to https://wiki.eclipse.org/CBI/aggregator/manual I have opened bug 501874 to track actually updating the document so it makes sense in its new home. = = = = = = I have checked the "Eclipse_b3" category page, at https://wiki.eclipse.org/Category:Eclipse_b3 and other sources and could find no other "wiki" pages we need. = = = = = = I have also looked at b3's "website" page at https://www.eclipse.org/b3/ but do not see anything there the aggregator needs. = = = = = = I have also look at the "downloads" site. The only thing to do there, IMO, is to *copy* the current .../modeling/emft/b3/updates-4.4 to .../cbi/aggregator/updates-4.4 That is just to have a starting point independent of the b3 project so the b3 project can be archived, without losing that "last build" from b3 project.
(In reply to David Williams from comment #19) > I have also look at the "downloads" site. The only thing to do there, IMO, > is to *copy* the current > .../modeling/emft/b3/updates-4.4 > to > .../cbi/aggregator/updates-4.4 > > That is just to have a starting point independent of the b3 project so the > b3 project can be archived, without losing that "last build" from b3 project. Correction to URL. There is already an "updates" site under .../cbi. The only thing there is the "license" p2 repository. So to have a consistent directory I structure, I think better to have .../cbi/updates/aggregator/4.4 or, perhaps .../cbi/updates/aggregator/ide/4.4 While I think it is unclear if we actually need a "headless" update site, I will also save a copy of the 4.4 "headless" version. It is currently at .../modeling/emft/b3/headless-4.4 and I guess .../cbi/updates/aggregator/headless/4.4 Would work for now. (I am not really sure why there are two completely separate repositories for these two items (I guess to have quicker downloads of metadata?) but I am not sure we need to have them separate, in future. We'll see.
(In reply to David Williams from comment #20) As mentioned, I have "saved" copies of the 4.4 b3 aggregator in /home/data/httpd/download.eclipse.org/cbi/updates/aggregator/headless/4.4/ and /home/data/httpd/download.eclipse.org/cbi/updates/aggregator/ide/4.4/ By hand, I also update the p2.mirrorsURL property in the copied artifacts.jar files to point to /cbi/updates/aggregator/headless/4.4/ and /cbi/updates/aggregator/ide/4.4/
I have added some bugs to the "blocks" list, which mostly means they represent "next steps" in completing the "move" to its new home (updating documentation, etc.) But, the "move" itself is done and I think this bug can be closed. The main significance of this is that the EMFT.b3 project can now be "archived".
