On Mon, Sep 17, 2018 at 9:12 AM, Ed Merks <[email protected]> wrote:
> From the absence of commits for your changes, I assumed that Corrosion > would be using some generic URL to contribute to SimRel, i.e., a URL for > which the contents of the repository can change over time such that you > didn't need to update SimRel itself. > Right. > Looking at the details, it looks like you're using > http://download.eclipse.org/corrosion/snapshots/ as the URL. Several > other contributions you made 7 days ago use this same approach of pointing > at "snapshots". I was under the impression that the general policy for > SimRel contributions is that the URLs should point at stable locations (or > that the version of the contributions should be specified). To avoid > problems in the future, I would suggest that your SimRel updates to use > non-released versions (the development stream builds) of your contributions > ought to be done much earlier in the SimRel process; then the problems > would have been found much earlier (or at least could have been found much > earlier) > I fully agree with that, and supports is fully, and I realize that by doing this, I'm acting against a rule I support all the time and even I did write down in the wiki. One thing to notice is that while the doc is full of recommendation, it's still possible for h4c|<3rs like me to not honor those rule. I'd like to mention that if the build were failing in such case, it would prevent people from pushing such bad content. To me, SimRel build is too permissive. My faulty behavior is typically caused by prioritizing project community (so the patch cascade as fast a possible in EPP) over SimRel recommendations. Since Corrosion is a "leaf" project with very low audience, I thought I could let SimRel pick whatever is the latest and then to tag/promote the bits after SimRel release according to the content that goes into SimRel. Unfortunately, because we don't have resources to do more QA on Corrosion, a blocker was included in SimRel this time. The deep issue here isn't the URL, but more the absence of testing/QA. It's somehow exactly the same than releasing without testing But I hope that with Corrosion (and others) becoming more mature and also me -and hopefully some other people caring about the project at some point- becoming more used to the new schedule and not feel surprised that it's already too late, it will be easier to follow the rules. This all makes me wonder what is the general policy on the SimRel > contribution URLs and their stability. > It's documented in https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Format (as you can see, documentation is SimRel is perfect to cover your concerns, it's really my own fault here, and -partly- the fault of the tool not enforcing the rules strongly enough). > I.e., is it possible (should it be possible) to respin SimRel 2018-09 say > two weeks from today and end up with the same results as we do when we > respin today? > With URLs like /snapshots or /milestones and moveable content in them and no specific version, it's very unlikely that the build is reproducible. But again, if everyone were playing by the rules of https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Format then it would be reproducible.
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
