Re: [orbit-dev] A (small) change to our retention policy ...

[David M Williams <david_williams@xxxxxxxxxx>]

Good suggestions ... below is what I wrote
for now ... in http://wiki.eclipse.org/Orbit/Promotion%2C_Release%2C_and_Retention_Policies#Bundle_Retention_in_active_builds
 
 ... improvements welcome. 

I'm not sure what to say about the psf
file ... I do not personally use it (maybe I will now :) ... and there
is one produced during a build as well as the one in cvs. I assume the
one on download page is based on what's built? Or is it just checked out?
(It does seem different, so assume the build one is auto created, and the
one in cvs is "hand" created ... so I just said "update
if desired".  Since apparently it is updated as desired to begin
with. 

Good idea to leave in the iplog. I could
be convinced to remove it ... but makes it _much_ easier for users trying
to find some old version. 

I think the "exclude" list
is almost always fine, since usually specified with wild cards, such as
"icu*" ... but have mentioned it, in case becomes relevant for
some cases. 

I've also added a note about original
Orbit CQ. I don't think there's anything mandatory to do there ... but
as with the IP logs, provides a nice documentation trail.

• Mechanics: When a bundle is to be removed from active builds, the following steps should be followed:
  • have a bugzilla entry that mentions what is being removed, when, and ideally states the "last good R-build" that contains the old version.
  • remove bundle entry from the feature.xml file (and release it for a build, at some point, when ready)
  • remove the bundle entry from the bundles.map file.
  • leave the entry in the IP Log file, but add a note that says something similar to "No longer in active builds since this version is no longer current. If required, please get from an older R-build repository, CVS, or open a bugzilla if needs to be re-instantiated in active builds".
  • ideally should update the original "Orbit CQ" to simply mention that version is no longer actively built by Orbit. This is just to help cross-reference information, in case someone is looking for that bundle. Orbit does, technically, still "distributes" it, since it is available in old repositories ... it is just an informational message.
  • update the orbit.psf file if desired.
  • There are some other files that may need updating ... but they usually will not, but can check these if there seems to be some problem:
    • the list of exclude-from-pack-conditioning list in buildutilities.xml (in org.eclipse.orbit.releng.builder project),
    • the config.properties in layout tests (in org.eclipse.orbit.releng.tests project).
      
      
      

From:      
 DJ Houghton <DJ_Houghton@xxxxxxxxxx>
To:      
 Orbit Developer discussion
<orbit-dev@xxxxxxxxxxx>
Date:      
 01/13/2011 10:48 AM
Subject:    
   Re: [orbit-dev]
A (small) change to our retention policy ...
Sent by:    
   orbit-dev-bounces@xxxxxxxxxxx

---

Thanks for putting this together, David.

I think we should also explicitly have instructions on the wiki page for
the map, ip log, and psf files. (the map file is mentioned in passing on
the page but we should call it out I think) Do you think that the old entries
should remain in the ip_log and psf files? (my vote is to remove them from
the map file and leave them in the other 2 files)

Also, is there anything in the builder that needs to be changed? Specifically
I'm thinking about the "ignore processing pre-built JARs" and
also the file that we created for the test suite layout exceptions. (I
think that file might be ok with old entries)

David
M Williams ---01/12/2011 03:47:11 PM---Committers, We document our project's
retention policy in

From:	David M Williams <david_williams@xxxxxxxxxx>
To:	Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
Date:	01/12/2011 03:47 PM
Subject:	[orbit-dev] A (small) change to our retention policy ...
Sent by:	orbit-dev-bounces@xxxxxxxxxxx

---

Committers, 

We document our project's retention policy in 
http://wiki.eclipse.org/Promotion%2C_Release%2C_and_Retention_Policies

But, I'd like to change part of it ... it has to do with the part about
re-building old stuff. We would still retain forever anything ever delivered
... this just has to do with re-delivering old versions that are no longer
used in active builds or releases under development. 

The new policy is at 

http://wiki.eclipse.org/Orbit/Promotion%2C_Release%2C_and_Retention_Policies#Bundle_Retention_in_active_builds

To see how this "diffs" with previous policy, see 

http://wiki.eclipse.org/index.php?title=Orbit%2FPromotion%2C_Release%2C_and_Retention_Policies&diff=234721&oldid=232803

If any committers feel this is a bad policy, please say so and we can discuss
on this mailing list. 

If anyone sees any small improvements in wording/spelling, etc., feel free
to update the wiki directly. 

There is a couple of reasons I'd like to make this change now: 

1. We need to practice and promote efficient computing and use of our resources
... and our builds are getting overly long, and our build-repositories
too large. 
I'm not sure there will be any huge reduction in time or size ... but the
old policy seemed way too conservative, leading to even longer builds and
larger repos ... I know first had of some very old, no longer used bundles
and it makes no sense to build them over and over and over again for years,
simply because there is not a fourth version coming along. 

2. We will be promoting more use of p2 repos and archived p2 repositories
... and the smaller we can make those, the better .... efficient computing
multiplies its returns :) 
Our current repo (zipped up) is nearly 200 Meg. I'm not sure how much smaller
the new policy will make it ... but ... 200 Meg seems too large to use
on a practical day-to-day basis. 
So, I don't want it to get even larger, under the old policy. 

3. The old policy seemed to be worded in a legalistic way that was intended
to provide some absolute rules about (not) removing things ... but as I
looked at some old things of mine to remove, I realized this old policy
did not leave any room for "committers judgement" ... and it
should. 

So ... it would be wrong to remove things willy nilly from active builds
... simply because "you" were no longer using it ... but, it
is also wrong to build something over and over and over again for years,
when we know no one is using it. (And, in many cases, even if someone did
still need it, it is still there in an old repo ... no need to rebuild
it over and over). 

Let me know if questions or objections. 

Let's set an aggressive "close" date of one week ... 1/19/2011.
If no objections by then, we will consider the new policy official, and
then we'll have some time to remove some of the more obvious old things
before M5. 

Thanks all, 


_______________________________________________
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