|Re: [cross-project-issues-dev] 2018-12 opt-in|
If we start auto-disabling contributions I can guarantee that we will not get a first spin off the ground. Try to remove EMF's contribution automatically and see how well that actually works.
On 04.10.2018 12:01, Ed Willink wrote:
Hi Yes a mandatory manual enabling at M1 was very disruptive, but ...There has long been an expectation that releases should demonstrate that they are SimRel compatible. i.e. build against the latest Orbit + platform + ... A maintenance release contribution is therefore unavoidable.The tolerance of 'latest & greatest' aggrcon contributions is to be terminated, so projects will have to make a manual *.aggrcon change anyway.Perhaps the automated disable can be enforced at M2 for those projects that have failed to make a contribution prior to M2+0 day.Regards Ed Willink On 04/10/2018 10:48, Matthias Sohn wrote:On Thu, Oct 4, 2018 at 11:21 AM Pierre-Charles David <pierre-charles.david@xxxxxxx> wrote:On 03/10/2018 23:13, Wayne Beaton wrote:No explicit opt-in is required for returning projects. We're going to sort this out automatically from the aggregation files.Could you clarify how exactly this will be "sorted out"? From what I understood at yesterday's planning council meeting , the idea was to disable everyone's contribution at the start of a new cycle and to expect each project to explicitly re-enable its contribution before M1. Is that correct? After discussing with other project leads here at Obeo we feel this approach (if this is indeed what is proposed) would be too disruptive. We've tried this before, and the result was not good, with the first milestone(s) often completely broken. It would be enough for a single project on which others depend to be late to completely break the aggregation. Given the reduced number of milestones we have now, this would be really bad.+1I think the idea of relying on an explicit action in "the aggregation files" to declare intent is good, but using the enablement flag too risky. Maybe we could have another mechanism in the repo for that. How about something as simple as a "participation.txt" text file with a single line per project: PMF: 2018-12 XWT: 2018-12 actf: 2018-12 acute: 2018-12 birt: 2018-12 ...I think there is no need to repeat this version name for all entries in this file. Use yaml or json format instead to avoid the repetition participation.yaml: version: 2018-12 projects: - PMF - XWT - actf - acute - birt ...Declaring intent to participate would simply involve editing the corresponding line with the version of the next release. Regards, Pierre-Charles David (Obeo)  https://wiki.eclipse.org/Planning_Council/October_3_2018 _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top