Bug 489042 - SWT's process should be "ready for an I-build" at any time
Summary: SWT's process should be "ready for an I-build" at any time
Status: CLOSED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.6   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2016-03-04 11:31 EST by David Williams CLA
Modified: 2020-08-03 04:07 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Williams CLA 2016-03-04 11:31:50 EST
Perhaps there is a better title, but what I mean is related to the way the qualifier is updated. 

A recent example motivated me opening this bug. 

We have started to do Y-builds based on a few projects that have BETA_JAVA9 branches. And the first one, yesterday, had comparator errors due to SWT not having updated qualifier. 

http://download.eclipse.org/eclipse/downloads/drops4/Y20160303-0800/

Or more exactly, 

http://download.eclipse.org/eclipse/downloads/drops4/Y20160303-0800/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt

= = = = = = = = 

What is unclear to me, is why you can't "update qualifier" every time there is any change? I understand then some of them may be "wasted", but ... as far as I know they are not in short supply. 

I am sure you may have a reason that I simply do not know about, but ... I do think it's important we should be able to do an I-build (or Y-build) at any time and get the correct version of SWT. 

= = = = = = = = 

If it is a matter that "you are not yet sure" if something should go into an I-build (or Y-build) perhaps we should reconsider the integration/master approach?
Comment 1 David Williams CLA 2016-03-04 11:33:40 EST
I've CC'd Markus as he might better understand your system and give advice (perhaps just to me! :)
Comment 2 Markus Keller CLA 2016-03-04 16:10:08 EST
(In reply to David Williams from comment #1)
> I've CC'd Markus as he might better understand your system and give advice

Not good enough, passing the ball to Lakshmi and Arun.

Could be a result from bug 477711. However, I don't think a fully-automated build input is feasible at this time, since the qualifiers of all SWT bundles still need to be synchronized. This could only work for free if we accepted a "build input" commit after each and every real commit.

I guess the best solution for now would be a way for David (or the SDK build) to force a build input. I know that the native build can't currently run on eclipse.org infrastructure, but maybe the simpler tagging job could be moved over?


BTW: If you wondered about the unanticipated change in org.eclipse.ua.tests: It's OK.

In http://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/?id=f562c7ab0b00eed80a4ece7b6cbfd7225bc263ee , the internal org.eclipse.help.internal.UAElement#getChildren(Class) got generified in an incompatible way that changed the return type from Object to Object[]. No problem, since it's not API and just referenced from a test, but we may have to touch org.eclipse.ua.tests to silence the problem.
Comment 3 David Williams CLA 2016-03-05 00:05:45 EST
(In reply to Markus Keller from comment #2)
> (In reply to David Williams from comment #1)
> > I've CC'd Markus as he might better understand your system and give advice
> 
> Not good enough, passing the ball to Lakshmi and Arun.
> 
> Could be a result from bug 477711. However, I don't think a fully-automated
> build input is feasible at this time, since the qualifiers of all SWT
> bundles still need to be synchronized. This could only work for free if we
> accepted a "build input" commit after each and every real commit.

Thanks for the comments, Markus. I definitely agree with bug 477711 so do not mean for that to be reverted. 

I also am not that concerned about things being "off" an hour or two but seems now things are off for "days" at a time. 

Plus, things often do not "go right" even before an I-build so things are not tagged correctly due to a failed build, or network issue (if I have heard correctly). 

Is there a reason the "master/integration" approach was abandoned? 

That is, I-builds could come from "integration branch" (for SWT) and your initial check-in of binaries would go into "master" for nightly builds. Then when you are ready at whatever point you want, not necessarily "right before an I-build", perhaps even multiple times a week, or at times skip weeks, you could update the 'tag' in question, and merge master into integration? (Or, rebase, or whatever best approach is). 

I suspect, then, your "tagging" and your "merge" could be automated in the same script? 

These are all just suggestions to improve our process. No criticism. 

Thanks,
Comment 4 Eric Williams CLA 2018-05-11 16:00:50 EDT
Is this still relevant?
Comment 5 Sravan Kumar Lakkimsetti CLA 2018-05-14 01:51:17 EDT
(In reply to Eric Williams from comment #4)
> Is this still relevant?

We have SWT tagging and qualifier update running 1 hour before every I build. Also I-build will fail if the qualifier update is not done. I would say this is not that relevant anymore. 

but we can still improve a bit on updating qualifier every time.
Comment 6 Eclipse Genie CLA 2020-08-03 04:02:48 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 7 Sravan Kumar Lakkimsetti CLA 2020-08-03 04:07:20 EDT
We are running SWT build input as part of I-build now. So we will not see this problem anymore