Community
Participate
Working Groups
We'll use this bug to track the release We require IP Team approval of the IP Log. We require PMC approval of the release and review materials.
> We require IP Team approval of the IP Log. The IP Log is approved.
@Wayne: does this mean I can now promote the build and tag the code for 0.2.0?
(In reply to Mickael Istria from comment #2) > @Wayne: does this mean I can now promote the build and tag the code for > 0.2.0? Nope. It means that I have the IP Log approval. I haven't seen the PMC approval yet (I have a bit of a backlog). Independent of that, however, you can (and should) be promoting your release bits into the aggregate build.You just can't declare the release the community until after the Release Review date.
I thought you were talking about aCute 0.1.0 for which I scheduled a release for May 30th: https://projects.eclipse.org/projects/tools.acute/releases/0.1.0 . However, I didn't create the release review so I'm a bit late on schedule. As I'm dealing I honestly don't have the time to release them all in parallel and rush on project release just on the day of the release, it's not something that works for me. I prefer having the release approved earlier (like now) so I can prepare it, place it in its final location, update aggregator and so on, and the only thing I need to do then is to replace the content of the /latest repo so it gets more accessible. Can the IP Log that was approved for aCute 0.2.0 be used to approve aCute 0.1.0? Given the lack of plans for the project in the next month, it's very likely that 0.2.0 gets delayed and that 0.1.0 gets into Photon.
@Wayne: Do you have a link to the IP Log approval?
(In reply to Mickael Istria from comment #5) > @Wayne: Do you have a link to the IP Log approval? It's in IPZilla. Since these links are restricted access, I don't share them.
(In reply to Mickael Istria from comment #4) > I thought you were talking about aCute 0.1.0 for which I scheduled a release > for May 30th: > https://projects.eclipse.org/projects/tools.acute/releases/0.1.0 . The IP Log that started this whole thing referenced 0.2.0. Frankly, this is one of about 80 of these things so I don't always check everything that's occurring around any particular project. The 0.1.0 Release Record lists June 6th as the release date. Not sure where May 30th comes from. > However, > I didn't create the release review so I'm a bit late on schedule. > As I'm dealing I honestly don't have the time to release them all in > parallel and rush on project release just on the day of the release, it's > not something that works for me. I prefer having the release approved > earlier (like now) so I can prepare it, place it in its final location, > update aggregator and so on, and the only thing I need to do then is to > replace the content of the /latest repo so it gets more accessible. What did I say to suggest that this is not acceptable? This is SOP. Do this. > Can the IP Log that was approved for aCute 0.2.0 be used to approve aCute > 0.1.0? Sure. > Given the lack of plans for the project in the next month, it's very likely > that 0.2.0 gets delayed and that 0.1.0 gets into Photon. Aren't we getting a little late in the process to be hedging? We're past RC1, swapping around versions is a little dangerous at this point.
(In reply to Wayne Beaton from comment #7) > The 0.1.0 Release Record lists June 6th as the release date. Not sure where > May 30th comes from. I just changed the release date to leave time for the release review. It was May 30th before, but as I forgot to trigger the release review, I shifted > What did I say to suggest that this is not acceptable? This is SOP. Do this. Ok, I overinterpreted what you meant by "declare community the release". I thought it prevented to use final locations; but glad to be reminded it doesn't. > > Can the IP Log that was approved for aCute 0.2.0 be used to approve aCute > > 0.1.0? > > Sure. Thanks. > > Given the lack of plans for the project in the next month, it's very likely > > that 0.2.0 gets delayed and that 0.1.0 gets into Photon. > > Aren't we getting a little late in the process to be hedging? We're past > RC1, swapping around versions is a little dangerous at this point. Ok. And if there is no diff between 0.1.0 and 0.2.0, is it ok to just copy 0.1.0 as 0.2.0 (not change bundle version) and make next version be 0.3.0? So the release plan and review is still there, but it's actually the same code/build under the hood?
(In reply to Mickael Istria from comment #8) > Ok. And if there is no diff between 0.1.0 and 0.2.0, is it ok to just copy > 0.1.0 as 0.2.0 (not change bundle version) and make next version be 0.3.0? > So the release plan and review is still there, but it's actually the same > code/build under the hood? Sure. Are you saying, then, that we'll mark the 0.1.0 release as WONTFIX and focus on 0.2.0? Assuming yes, please get PMC approval.
(In reply to Wayne Beaton from comment #9) > Are you saying, then, that we'll mark the 0.1.0 release as WONTFIX and focus > on 0.2.0? Yes, I think it's better to abandon 0.1.0 release.
Should this one be closed now?
> Should this one be closed now? I think so.
AFAICT, this review was not actually completed. I see no evidence that the PMC was asked to approve the review in the tools-pmc list. However, it looks like we allowed this to slip through the cracks and I see no point in pursuing it further. Let's please make sure that the process is followed for the next release.
