Community
Participate
Working Groups
I wasn't aware that you could click directly on commit link in the patch set section. I'd like to see this as a normal link, e.g. underlined, with link coloring. Perhaps there is a reason this wasn't done?
I am not sure if there was a particular reason. It would make sense to use a Link widget or other means to make it more obvious that it's a link.
Miles, will you be able to take this on for 2.0? Otherwise we should remove the milestone.
Let's keep it on 2.0 for now as a "nice to have" and push it back if we have to.
Let's do it the other one way round to make sure we focus on the highest priority tasks since we are getting close to the release date. If we have capacity and get to this we can always pull it back onto the milestone.
I've made a patch: https://git.eclipse.org/r/#/c/13421/
Hi Lily, thanks! We can't accept contributions for Kepler now and I'm focusing on getting things set for that, so please be patient as it may take a couple of weeks for me to be able to have time to take a good luck at it.
Merged https://git.eclipse.org/r/#/c/13421/. Thanks, Lily! Now, if only we got something useful when the user clicked there.. bug 410440
Steffen, I hope it's ok to put these into the 2.0.1 maintenance release?
(In reply to comment #8) > Steffen, I hope it's ok to put these into the 2.0.1 maintenance release? Yes, we can merge contributions for service releases. Please note that none of the changes were cherry-picked (or merged as long as there is no diversion of branches) for 2.0.1, yet. 2.0.1 will be released from the e_4_3_m_3_9_x branch.
(In reply to comment #9) > Please note that none of > the changes were cherry-picked (or merged as long as there is no diversion of > branches) for 2.0.1, yet. 2.0.1 will be released from the e_4_3_m_3_9_x branch. Ok, I'm not sure I understand what this means. ;) Are we saying that rather than release 2.0.1 off of master, we'll be picking the changes off of master on to the e_4_3_m_3_9_x branch? And that master then becomes the new Luna branch such that for say 2.1 we'll also be pulling all of the changes off master to deliver under Kepler SR1 and SR2?
(In reply to comment #10) > Are we saying that rather than > release 2.0.1 off of master, we'll be picking the changes off of master on to > the e_4_3_m_3_9_x branch? Yes. That's how we have done this in the past. > And that master then becomes the new Luna branch such > that for say 2.1 we'll also be pulling all of the changes off master to deliver > under Kepler SR1 and SR2? We don't merge branches once they have diverged. Any change that is supposed to go into 2.0.1 needs to be cherry-picked onto the maintenance branch.
(In reply to comment #11) > We don't merge branches once they have diverged. Any change that is supposed to > go into 2.0.1 needs to be cherry-picked onto the maintenance branch. Have they though? I'm just asking because I'm curious about what the cutoff is from what we consider an enhancement/fix to Kepler vs. a new stream for Luna. Are we really at the point where we don't want to be delivering off of master? I'm not anticipating any truly new features for a while here and it would be convenient to treat them the same at least for the time being. I can't foresee any changes that we'd really want to hold for Luna but maybe I'm not understanding something here.
I should have pointed out that we can of course change the policy (but the branch was already created a while ago following process). So far master and the service branch have been moving side by side but that's only because we haven't updated versions. I'm generally not a big fan of simply merging all changes from master on to the service release branch. This discourages larger changes and particularly feature work on master (which by definition should not be released in SRs). We have successfully worked this way for several years and there have been discussions on the planning council in the Juno cycle emphasizing the importance of considerate maintenance on the release train to ensure quality releases since other projects were making major changes in SRs. I would suggest to bring this up on a call or mailing list to and discuss the implications in a wider audience before making adjustments to the process.
Personally, I think the current process makes sense. If, when we do the SR, it turns out that we want to include all the changes on master, it is easy to fast forward the branch.
(In reply to comment #14) > Personally, I think the current process makes sense. If, when we do the SR, it > turns out that we want to include all the changes on master, it is easy to fast > forward the branch. Ok, that was my real concern. I don't want to add to the maintenance burden or have us forget something. As I said I think everything we'll be doing in short term belongs in the SR. I'd like to see 2.1 in the SR as well. And this is a more general conversation, but part of me (the devil's advocate part) questions the emphasis on SRs being purely "fixes" for the release train. I mean, I can totally understand this from a release train consumer point of view. You don't want to break someone else's SR. But for a project like Reviews that doesn't have release train consumers, it seems sort of artificial. Assuming that you feel like quality isn't impacted [yes I know a big if, but right now the only direction 2.0 can go is up ;)] why *shouldn't* users be able to get the latest and greatest w/o having to enable a non-Kepler update site?
(In reply to comment #15) > And this is a more general conversation, but part of me (the devil's advocate > part) questions the emphasis on SRs being purely "fixes" for the release train. > I mean, I can totally understand this from a release train consumer point of > view. You don't want to break someone else's SR. But for a project like Reviews > that doesn't have release train consumers, it seems sort of artificial. Assuming > that you feel like quality isn't impacted [yes I know a big if, but right now > the only direction 2.0 can go is up ;)] why *shouldn't* users be able to get the > latest and greatest w/o having to enable a non-Kepler update site? You could certainly make an argument for the Gerrit connector for that. I would object for all other Mylyn components which are included in several of the EPP packages though. That would mean we would have to release and test Reviews 2.1 against Mylyn 3.9 (rather than 3.10 which is going to be released from master) and coordinate the 2.1 release with the Kepler SR schedule and ensure that release review etc. is completed in time and someone would need to manage the Kepler contribution to consume a mixed set of features. It can certainly be done but we need to have conversation who is going to be managing Kepler participation moving forward first and then we can consider doing this if someone is willing to take on the work. I'm okay with postponing the version update until we have merged more fixes to keep the cherry-picking overhead as low as possible but we need to do it at some point in order to release newer snapshots.
That said, we could update to 2.0.1 first and do the split branches once the first feature change is merged that would warrant a 2.1 version update.
(In reply to comment #17) > That said, we could update to 2.0.1 first and do the split branches once the > first feature change is merged that would warrant a 2.1 version update. +1
