Re: [cross-project-issues-dev] 2018-12 opt-in

[Ed Willink <ed@xxxxxxxxxxxxx>]

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 [1], 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.
> +1
>
> > I 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)
> >
> > [1] https://wiki.eclipse.org/Planning_Council/October_3_2018
> >
> > _______________________________________________
> > cross-project-issues-dev mailing list
> > cross-project-issues-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus