Re: [orbit-dev] Declaring Orbit Juno Build and repository: R201205260629

[David M Williams <david_williams@xxxxxxxxxx>]

Orbit Committers, 

I never did say, so will now, I have
turned off the Orbit "builds" since we are done for Juno. I will
turn them on again near end of June, once we've released Juno. This is
mostly to avoid confusion about "what's current". 

Also, I would appreciate Orbit Committers
not making changes to Orbit "released" content until after the
Juno release, just in case we need to "respin" Orbit for a blocking
bug. If there is "new stuff" there, then we will have to make
a branch and make sure we include in the respin only things we really want
to change in a new R-build. * I think the few "name fixes" that
have been done (see bug 380985) are fine and likely we would want to include
those, if we did a respin for blocking bugs .... but ... they themselves
do not constitute "blocking" status since they do not block someone
from using or adopting the current R build. *.  Sounds like we will
do for SR1, though. 

People are still welcome to check stuff
into head, etc., but do not change the map files or feature files (except
for above "name exceptions"). 

Part of the reason I bring this up now
is because if not having these builds running inhibits anyone from getting
work done, just say so, and we can reconsider. For example, if it prevents
work getting done in a non-Juno project, that would be bad. If that's the
case, we can reconsider the rules, and we would just know in advance to
do a respin we would  need to do a branch ... its a little more work
for me ... but, not all that hard, so its the sort of thing I'd prefer
not to do, but could, but would expect someone to say they really need
it before I do the extra work and wouldn't hurt to have "extra"
communication around this time of year around this kind of thing, anyway.


If this rambling note is confusing ...
or, any other questions ... don't hesitate to ask. 

Thanks, 






From:      
 David M Williams/Raleigh/IBM@IBMUS
To:      
 Orbit Developer discussion
<orbit-dev@xxxxxxxxxxx>, cross-project-issues-dev@xxxxxxxxxxx, 
Date:      
 05/26/2012 03:21 PM
Subject:    
   [orbit-dev]
Declaring Orbit Juno Build and repository:        R20120526062928
Sent by:    
   orbit-dev-bounces@xxxxxxxxxxx

---

This will be the build and repository
that Orbit offers to those contributing to Juno. Please move your build
scripts (or those newfangled "POMs"? :)  to use this new
build/drop/repository. 

http://download.eclipse.org/tools/orbit/downloads/drops/R20120526062928/repository/

The I and S builds produced during the year will be progressively removed
over the next week and by 5/31 I plan to have them all removed.  If
this exact date is a problem for anyone, and you need a few extra days
to make the changes required, just say the word, and what you need. Ideally
everyone would move in time for next RC, so in some of the common repository
reports, we can get a better idea if anyone is using incorrect bundles.

Such as, the non-unique-versions report looks pretty good (for Orbit bundle
reuse)
http://build.eclipse.org/juno/simrel/reporeports/reports/nonUniqueVersions.txt

Remember, and this is always true, there is always a small chance someone
might find a blocking problem in the next RC (or two) that might require
a change in an Orbit bundle. But that would be extremely rare (and would
really need to be a show-stopper, no mere bad bug will do).  This
is always the case, just wanted to remind everyone, especially new comers.

Good opportunity to give another important reminder, especially for new
comers that applies for the rest of the year (dev cycle): Use only Orbit
R-builds for your releases (even if off-cycle).  

Wordy version: For Orbit bundles, you (your Eclipse Foundation projects)
should only ever use "R-builds" in your own projects' releases,
even if they are off-cycle. For example, if you release in April, May,
or December, and use some I or S build, there is a great chance that bundle
(not merely the URL) will disappear, since it may require changes by the
time the R-build comes around, and the R-build bundles are the only ones
we retain indefinitely. If you do have an off-cycle release, and you need
something "new" in Orbit, that is not in an existing R-build,
then you should ask, on orbit-dev list or in orbit bugzilla releng component
(preferably through an Orbit committer) that there be another, off-cycle
R-build of Orbit. This is actually true of any pre-reqs you might have
on any other Eclipse Foundation Project, but Orbit causes the most confusion
in this area (for understandable reasons) so thought I'd remind everyone
now that we are quite happy to work with projects that need SR1, SR2, or
even off-cycle, R-builds. We'll work out the details as the need arises,
but you need to let us know of the need. 

Thanks,

David
M Williams---05/26/2012 02:25:30 PM---  Download Page:

From: David M Williams/Raleigh/IBM@IBMUS
To: orbit-dev@xxxxxxxxxxx, orbit-dev@xxxxxxxxxxx,
Date: 05/26/2012 02:25 PM
Subject: [orbit-dev] Declaring Build:
R20120526062928
Sent by: orbit-dev-bounces@xxxxxxxxxxx

---

Download Page: http:
//download.eclipse.org/tools/orbit/downloads/drops/R20120526062928

_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev

_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev

Attachment: STG44393
Description: Binary data