Community
Participate
Working Groups
If we decide to move the Platform projects from CVS to Git, we need to ensure the RelEng Release tool works with Git repositories.
See bug 328745, bug 343320. Some work has been done, the tool is missing some pieces.
(In reply to comment #1) > See bug 328745, bug 343320. Some work has been done, the tool is missing some > pieces. That work seems to be outside of Platform's Releng tool.
On bug 343320, comment 12, John suggested to move Git Releng Tool back into Platform/Releng. I'm stepping forward to do this once bug 328745 is fixed.
(In reply to comment #3) > On bug 343320, comment 12, John suggested to move Git Releng Tool back into > Platform/Releng. I'm stepping forward to do this once bug 328745 is fixed. I'm just looking into what process we need to follow to move the code across Eclipse projects. I'll follow up here when I know more.
Note that this not only means to implement the 'Release' scenario. I also often use things like 1. select some projects 2. Compare With > Released 1. select some projects 2. Replace With > Released I expect that I can select Git and CVS projects at the same time and not be forced to do this in two steps. Another scenario: 1. select a map file 2. Team > Load Map Projects
(In reply to comment #5) > I expect that I can select Git and CVS projects at the same time and not be > forced to do this in two steps. This is a nice convenience but this functionality will only be needed for a few months at most while we transition. I think it would be better to keep Git/CVS functionality separate so it will be easier for us to remove dependency on cvs plugins in the future (or at least make the dependency optional). > Another scenario: > 1. select a map file > 2. Team > Load Map Projects There isn't a practical way to do this with Git. It only really works if all bundles have the same tag.
(In reply to comment #6) > (In reply to comment #5) > > I expect that I can select Git and CVS projects at the same time and not be > > forced to do this in two steps. > > This is a nice convenience but this functionality will only be needed for a few > months at most while we transition. I have the Releng tool at a common location used by all my workspaces. To make patches for older releases CVS support will continue to be required. Yes, I could change my setup and work with various copies of the Releng tool, but that's not very practical. > > Another scenario: > > 1. select a map file > > 2. Team > Load Map Projects > > There isn't a practical way to do this with Git. It only really works if all > bundles have the same tag. Maybe time to tag all bundles with the same tag again, like we did in the early days ;-).
(In reply to comment #4) > I'm just looking into what process we need to follow to move the code across > Eclipse projects. I'll follow up here when I know more. John, any news here?
(In reply to comment #4) > I'm just looking into what process we need to follow to move the code across > Eclipse projects. I'll follow up here when I know more. As I remember we were also blocked by missing Git repo for releng, bug 360157. I think it is fixed now. John, do you have details about the process of moving the code between projects. If there is no problem with it, we could do it now.
(In reply to comment #9) > As I remember we were also blocked by missing Git repo for releng, bug 360157. > I think it is fixed now. John, do you have details about the process of moving > the code between projects. If there is no problem with it, we could do it now. Yes we can do it now. The work is to figure out how to transfer the changes back while keeping the author information intact for any contributions made while it lived in EGit.
Actually bug 360157 only migrated doc and org.eclipse.releng (map files). The releng tools haven't moved yet.
I had a discussion with Szymon and we came up with several possible ways to continue work on this bug without waiting for bug 362670: * Copy org.eclipse.egit.relengtools* from EGit to eclipse.platform.common/bundles. * Create a branch in org.eclipse.releng.tools (CVS), squash all the commits from EGit and use them start off the branch, then apply patches from bug 343320, bug 357061. * Create a branch in org.eclipse.releng.tools (CVS) and start the work on the tool from the scratch. Given the current shape of it this shouldn't be a huge effort. Then, when Kim is back, we could decide on bug 362670 how we want the relengtools repo to look like in git.
(In reply to comment #12) According to Dani we need to wait till PMCs define a process for releasing changes in our new Git repositories. Then we can start working on the tool helping with the process. > * Create a branch in org.eclipse.releng.tools (CVS) and start the work on the > tool from the scratch. Given the current shape of it this shouldn't be a huge > effort. +1 from me. If we had the process defined and there was no Git repo, we could start working on a cvs branch for releng.tool.
(In reply to comment #13) > (In reply to comment #12) > According to Dani we need to wait till PMCs define a process for releasing > changes in our new Git repositories. Then we can start working on the tool > helping with the process. Yes, we need to decide whether, and if so how quickly, we switch to a more Git-like release process. We will discuss it in the next PMC call. Until then, we can make sure the project is moved from CVS to Git.
(In reply to comment #14) > Yes, we need to decide whether, and if so how quickly, we switch to a more > Git-like release process. We will discuss it in the next PMC call. Until then, > we can make sure the project is moved from CVS to Git. I thought we already decided that at the architecture call two weeks ago. While we might need some new tools to help with the two-branch development model, I don't think that removes need for most of the current releng tools to work with git. For example compare with released, copyright checking, and there might still be cases where we need to manually perform a release (maybe maintenance builds).
(In reply to comment #15) > (In reply to comment #14) > > Yes, we need to decide whether, and if so how quickly, we switch to a more > > Git-like release process. We will discuss it in the next PMC call. Until then, > > we can make sure the project is moved from CVS to Git. > > I thought we already decided that at the architecture call two weeks ago. I don't think we came to a final conclusion. If so, we should summarize this and send out a note. > While > we might need some new tools to help with the two-branch development model, I > don't think that removes need for most of the current releng tools to work with > git. For example compare with released, With the new model there will be a tag on each repo for each build that is equal to the build ID, so comparing shouldn't be a problem anymore. I would expect that only the builder would deal with map files in the new world. > copyright checking Yes, that's bug 345669. Maybe Tomek should start with this one, as this is currently something we would not want to do manually? > and there might still be cases where we need to manually perform a release > (maybe maintenance builds). If that's the case one could do it "manually" as we currently do. I only want to make sure we spend our limited resource on those things which we really need in the long term.
(In reply to comment #13) > (In reply to comment #12) > > * Create a branch in org.eclipse.releng.tools (CVS) and start the work on the > > tool from the scratch. Given the current shape of it this shouldn't be a huge > > effort. > > +1 from me. If we had the process defined and there was no Git repo, we could > start working on a cvs branch for releng.tool. +1.
We discussed it this week in the PMC call. We will go away from the current release/tag process to a more Git-like workflow where the daily work is done in 'master' (as before) and the I-builds are run from a separate branch (e.g. 'integration' or 'i-build'). The release engineer's task will be to update that branch with the relevant commits (e.g. rebase or cherry-pick) after running the tests. John offered to write the script that does the automated tagging and that updates the changed bundles in the map files. The goal is to start with this for the 3.8 builds next week after the I-build. As a consequence we won't invest time into Releng Tool's release wizard at this point and focus on the Copyright tool instead. Note that Compare With > Released and Replace With > Released will be an easy task since all repositories will get a common tag for each build (even though we will update the map files only for the changed projects).
