| Re: [cdt-dev] Releases |
They don't show up in the repo so no one can install them. That's pretty removed.
Sent from my BlackBerry 10 smartphone on the Rogers network.
It looks like I'm missing something. Removing the feature from category.xml doesn't remove the plugins from the release, does it?
-sergey
On Mon, Aug 18, 2014 at 8:13 PM, Doug Schaefer <dschaefer@xxxxxxx> wrote:
The LaunchBar is not being release in this release. I firmly intend to be API complete when they are released. Which is the main reason they aren't ready.
Doug
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Sergey Prigogin [eclipse.sprigogin@xxxxxxxxx]
Sent: Monday, August 18, 2014 11:04 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
Platform UI has a rule that in the first contribution all packages, including the ones not containing the word "internal" in their names, should be exported with x-internal or x-friends. This way they don't become official APIs until the second release. Should this rule be applied to the launchbar plugins?
-sergey
On Mon, Aug 18, 2014 at 7:49 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
Hi,
as some of you might have seen, the cdt_8_5 branch is available. There is also a new job on our HIPP to build it.
I have created the release record and will continue filling it in: https://projects.eclipse.org/projects/tools.cdt/releases/8.5.0
Committers, feel free to continue working on new features for master, but nothing other than bug fixes should go into cdt_8_5.
If critical bugs are found, please remember to include their fix in both master and cdt_8_5.
I've pushed a patch on Gerrit for Doug to review that hides the Launch Bar feature: https://git.eclipse.org/r/#/c/31862/
I'll take the RC1 build once it contains that patch tomorrow.
I'll send the link to allow people to install and try it out once available.
Thanks
Marc
________________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Marc Khouzam [marc.khouzam@xxxxxxxxxxxx]
Sent: August 18, 2014 11:00 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
You're right, I forgot to mention I was going to create the branch today.
I'll create the 8.5 branch this afternoon, fixup the Jenkins jobs, change the category.xml file on the new branch and take RC1 from there.
BR,
Marc
----- Original Message -----
From: Doug Schaefer <dschaefer@xxxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Sent: 18/08/2014 9:45
Subject: Re: [cdt-dev] Releases
We're currently building Momentics and Wascana Arduino off of master so I can't remove the launch bar from it. Once someone branches this release, we can remove it from the repo's category.xml.
Doug.
________________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Marc Khouzam [marc.khouzam@xxxxxxxxxxxx]
Sent: Sunday, August 17, 2014 5:48 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
Hi,
I think it would be a good idea if the whole train followed a cycle with two releases with new features.
I like that you planted the idea already with others in the eclipse community. I'll talk to the committers
of other projects that I interact with and see if we can also plant the idea with them.
I'll also see if we can work our internal releases around the schedule you propose. I agree with you
that it would be a better schedule, if we could properly aligned with it.
As for now, as we had agreed the time is too close to change plans, I'll continue forward with the 8.5
release off the master branch.
Tomorrow (Monday) will be the tentative RC1 build. That means no more features after that (or the
final respin, if one is requested).
I'll start working on the release review as well.
I'd appreciate if people could be updated the N&N with the new features that were added to master.
Also, what is the plan for the Launch Bar? Should we simply remove it from the set of features
released with CDT. I believe that will hide it from users without requiring any effort to remove code.
Or do you prefer to take a different approach? I can update the o.e.cdt.repo/category.xml if you want
me to.
Thanks and I'll keep you posted on the progress.
Marc
________________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Doug Schaefer [dschaefer@xxxxxxx]
Sent: August 15, 2014 4:02 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
One last comment from me before I get back to work on all the fun things I'm doing :).
We agreed on a 4 month cycle, but SR-1 is only 3 months and it's over the summer. 3 months made sense when it was a real SR that gave us a chance to quickly fix bugs in the yearly release after it got into the hands of users. I don't think it makes sense to rush features into it in such a short time frame. I worry about the quality of it.
For next year, I'd like us to consider the proposal I made originally in this thread. Let the SR's be real SRs, releases with high quality, maintenance releases. To enable us to release new features more often, we'd insert a minor release at the beginning of December. That gives us a significant minor release for the Christmas holiday season (and, yes, I do know many people who'll try out a new IDE release for their hobby projects over the holidays). Adopters that want to take the SR's get a higher quality more stable release for their products.
And this is not just my wish for the CDT, I'd like to see the whole train adopt this strategy. I can tell you, it'll be hard to get people to do two minor releases in 3 months over the summer like we're trying to do.
Thanks for all your feedback, passion drives this community :)
Doug
________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Doug Schaefer [dschaefer@xxxxxxx]
Sent: Thursday, August 14, 2014 11:40 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
I'm not very happy with this. I hate having to follow through on a bad idea just to meet a deadline. That's not quality in my books. But if that's the will of the community, I won't get in your way. I'm also not going to do the release review. I have too many other things on my plate right now.
Doug.
________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Mikhail Khodjaiants [mikhailkhod@xxxxxxxxxxxxxx]
Sent: Thursday, August 14, 2014 2:07 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Releases
+1
On 14/08/2014 1:16 PM, Marc Khouzam wrote:
> I think SR1 should be focus on stability - but right now it is "whatever" happened to be in master.
Master is not an "open" branch in which we can put anything. Or at least, it has not been used that way since I joined the project. Master contains bug fixes and features that are ready to be released. This should be even more true considering some people regularly release to their users using a nightly build. Features that are not ready should stay in Gerrit, or get their own branch.
The agreement last August was that we wanted to release features to CDT users faster than once a year, and also that to minimize overhead, we would stay aligned with the release train. So, for a year now, we were following a plan to release 8.5 at Luna SR1. From this list, I get the impression many committers were working based on that assumption.
For better or worse, I think it is too late, one week before RC1 to change those plans. I don't think that is fair to committers, consumers or even users. Furthermore, we are mid-August and more than one of us are on vacation, so we have no guarantee committers will be able to cherry-pick commits as we are unexpectedly asking them to.
So, I think we should follow our commitment to release off the master branch for this release. We can continue the discussion about what would be the best release process going forward.
I'll take care of the release review since Doug is busy, although I'll need some pointers as to where/how to get started.
To summarize, my vote is that
- we release 8.5 off master
- we create an 8.5 branch after the RC1 build which will keep master open for new work
- we continue the discussion about CDT release schedule
Since this follows our original plan, I'm hoping it will cause the least disturbance.
Are people on board?
Thanks
Marc
________________________________
From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx> [cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>] on behalf of Alena Laskavaia [elaskavaia.cdt@xxxxxxxxx<mailto:elaskavaia.cdt@xxxxxxxxx>]
Sent: August 14, 2014 8:39 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
To Marc's point about re-testing if he cherry picks debug fixes - you were planning to re-test this anyway. With
controlled numbers of fixed it will be actually a lot easier to a) test b) do a release bureaucracy
And you don't have to cherry pick ALL bug fixes in debugger - only critial/most wanted ones. Same goes for other components.
I think SR1 should be focus on stability - but right now it is "whatever" happened to be in master.
On Thu, Aug 14, 2014 at 7:00 AM, Marc Dumais <marc.dumais@xxxxxxxxxxxx<mailto:marc.dumais@xxxxxxxxxxxx>> wrote:
Hi Doug,
FYI, Marc K.'s vacation is lasting two more weeks after the current one.
Regards,
Marc
MARC DUMAIS
Software developer
Ericsson
8500 Decarie
Ville Mount-Royal, Qc, Canada
Phone 514 345-7900 x45006<tel:514%20345-7900%20x45006>
marc.dumais@xxxxxxxxxxxx<mailto:marc.dumais@xxxxxxxxxxxx>
www.ericsson.com<http://www.ericsson.com>
On 08/13/2014 06:00 PM, Doug Schaefer wrote:
Thanks, Marc and sorry for disturbing your vacation. I appreciate your concerns. But comments below.
I would really like a minor release in December or we're missing the holiday season with these great new features. It would be really disappointing not to release the Launch Bar, and as a result my new Wascana work, until February. The LaunchBar will not be ready for feature freeze on Monday.
Two minor releases in two months is probably not what anyone had in mind. I think Derek was complaining already we were adding a new release.
Nothing prevents adopters from continuing to adopt the release train as a sole provider. They would just miss picking up the December release. In fact, that's how most adopters work anyway. They generally don't follow CDT releases when publishing their products. They just pick a build from whenever, test it, patch it, and then deliver it. No one is forcing you ("Ericsson") from adopting the December releases. You might want to wait until February anyway for all the early adopter bugs to be worked out.
If we do continue the 8.5 plan, we will need to prepare a release review ASAP. It needs to be filed by RC1 which is the end of next week. I will not have the time for that, so Marc you'll have some work if you are back next week. Mind you if there are no new features, it'll be easy. But then if there are no new features...
If we decide not to do a December release, then I propose we never try to release a minor release, and thus new features, in September. There's no way we can make any guarantees if we try it. That means you have two windows, Feb and June. I'm not sure that's good for the community. That's why 6 month cycles make more sense.
Thanks,
Doug.
________________________________
From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx> [marc.khouzam@xxxxxxxxxxxx<mailto:marc.khouzam@xxxxxxxxxxxx>]
Sent: Wednesday, August 13, 2014 4:44 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
Hi,
sorry for the delayed answer but I'm on vacation.
In summary I have the same concerns as Jeff and Derek and I would like to discuss this further before making a decision. Because, SR1 is very close, I suggest we don't change anything just yet and release 8.5 from master with SR1, I don't think there is a big drawback to that in itself. And we continue this discussion for 8.6 (which we can still decide to plan for December, although that is not my vote). I try to express my hesitations in detail below.
First, as Jeff pointed out, doing an 8.4.1 release off the 8.4 branch, instead of 8.5 from master implies more work this time because we were not expecting that. I was under the impression that the 8.4 branch was used by integrators that needed specific fixes for an older release; with that in mind, I didn't focus on duplicating bug fixes from the master branch to the 8.4 branch. So, like Jeff, and possibly others, I would need to go back and sift through the commits and cherry-pick the right ones. To do things right, I will need to test each bug fix. That's 14 bug fixes in the Debug component. I'm not very fond of retesting each one.
Second, some consumers of CDT repackage and release to their customers. This is our case. We include other projects in those releases, not just CDT, and those projects follow the Eclipse release train. This means that we probably cannot get away from having our internal releases match with SR1 and SR2. So a release in December will not provide much benefit for us, but will create more work (see next point).
The internal releases I mention have to be tested. We run thorough tests on each one (by 'we' I mean the Ericsson committers). Any issue found is fixed in open-source, so the community benefits directly from our efforts. As our packages include other projects that interact with CDT, we cannot assume everything will just work because CDT has a small SR release. So we will need to keep on testing each release. Now, we are discussing adding a forth release each year. That's another test cycle. That's more work.
I have other concerns (e.g., will users know to go fetch an un-aligned December release, compared to getting the release automatically with the SRs?), but let's focus on the ones above first.
We should focus on the benefits to the community, and my points might seem focused on Ericsson. In truth that is not the case. I still don't see the extra benefit to the community in having a December release compared to one at SR1 and one at SR2. Both allow the community to get features faster. If the SR1 cycle is too short, then the SR2 one comes shortly after; how is that different than a December release?
I do see a disadvantage to the community in the fact that if the committers are tied-up doing release efforts, we spend less time fixing bugs and working on features. So I believe it is a direct benefit to the community to minimize the overhead of the committers.
The only question mark for me is the release review. I am not familiar with it and don't understand how much work that entails. But besides that, I believe that not being aligned with the release train will slow us down with a benefit I have yet to understand.
But I'm enjoying the discussion :)
Marc
________________________________
From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx> [dschaefer@xxxxxxx<mailto:dschaefer@xxxxxxx>]
Sent: August 13, 2014 2:00 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
Thanks everyone. I'd iike to hear from the Ericsson gang before going much further.
To answer some of the questions below, IMHO, this is actually less releases than what we were planning. The SR's are now just maintenance releases which are a lot less work (no release review required, for example). We go from 3 minor releases a year to 2 which allows us to make each one more feature rich and gives us enough time to test them.
And, yes, sorry for the late call with 8.4.1. I was always worried about the 4 month cycle (which is actually only 3 with SR-1) and should have held my ground there. It will mean more work for folks like Jeff who want to get things in the SR.
If we decide this is the way to go, we'll need to firm up the 8.5 schedule. I don't mind doing it early in December, which is really only 2 months after SR-1, so if there are things that can wait that long, you wouldn't need to post it to the SR.
The more I think about having a holiday season release, the more I like it. Especially with the personal work I'm doing with Wascana supporting hobbyists on Windows and Arduino (and maybe even Raspberry Pi). It would be nice to get this all into their hands by then.
Doug.
________________________________
From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx> [eclipse.sprigogin@xxxxxxxxx<mailto:eclipse.sprigogin@xxxxxxxxx>]
Sent: Wednesday, August 13, 2014 1:18 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Releases
I'm OK with either proposed of the current release schedule. We are releasing approximately twice a month from nightly builds, so it doesn't make a difference for us.
-sergey
On Mon, Aug 11, 2014 at 11:10 AM, Doug Schaefer <dschaefer@xxxxxxx<mailto:dschaefer@xxxxxxx>> wrote:
Hey gang,
I'm back in Ottawa but on vacation for the rest of the week. But I didn't want this conversation to die without a conclusion, especially with Luna SR-1 so close.
Unless someone has something on master they really want to get into Luna SR-1, I propose the following schedule.
September - Luna SR-1. CDT 8.4.1 off of the 8.4 branch. Cherry pick any important fixes you have on master to the branch.
first half of December - CDT 8.5 from master. Just in time for the holiday season. We would make sure that Luna SR-1 users can upgrade to it.
February - Luna SR-2. CDT 8.5.1 fixes from the 8.5 branch.
June - Mars. CDT 8.6.
I think the 6 month cycle would really help get quality features in each release. It also reduces the number of release reviews we need to do :).
Thoughts?
Doug.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev