Back in the early wayback days of the eclipse trains, simrel opt-in was done via a wiki page [0],[1].
[0] https://wiki.eclipse.org/Helios/Participating_Projects [1] https://wiki.eclipse.org/Helios/Summary_of_Helios_Projects Then there was a portal-based flag [2]. [2] https://wiki.eclipse.org/Category:Kepler Using a wike page generates less email, so there's less of a spam factor / annoyance. But it also generates less email, so there's less of a reminder to opt in by the deadline. :D We could return to the simpler wiki ways, or acknowledge that there are now dozens of projects in the train, and it's kind of fun to see how many projects are actively announcing their intent to be at the party in September. (We could also use another tool too, if wiki is annoying. Doodle poll? Google Form? Google Spreadsheet? Evite to the GA launch on Sept 19? FB event on Sept 19?) On Mon, Jul 16, 2018 at 10:51 AM Ed Willink <e...@willink.me.uk> wrote: > Hi Wayne > > I don't think tracking the aggrcon will work since some projects specify a > 'my-build' repo and never need to touch the aggrcon; of course we all get > to enjoy the consequences of their broken builds. If everyone had to > specify a build specific repo, then aggrcon could work for this purpose. > > You seem to have ignored the at least 3-way suggestion of using the PMI > Release Record. Obviously this requires that a Release Record is created in > order to have somewhere for the checkbox. > > Regards > > Ed Willink > > On 16/07/2018 15:38, Wayne Beaton wrote: > > These "kind of annoying" announcement messages serve a couple of purposes. > > They ensure that project teams are actually engaged on the primary > communication channel for the simultaneous release. This comes in handy, > for example, when project teams change composition (e.g. key players move > on), knowledge gets lost, or project teams otherwise end up disengaged. > When we notice that projects are missing at the opt-in deadline, it's way > easier to mitigate than when we notice it at the end of the release cycle. > FWIW, we have to chase down at least a couple of projects every year. > > The requirement to make an explicit communication basically forces project > teams to create a release record and start their planning and communication > regarding the release. Of course, this presupposes that creating a release > record at the beginning of a release cycle is valuable. > > The Eclipse Development Process states, in part: > > Projects are required to make a project plan available to their community >> at the beginning of the development cycle for each major and minor release. >> The plan may be as simple as a short description and a list of issues, or >> more detailed and complex. > > > The Architecture Council is in the process of updating the Eclipse > Development Process. If anybody would like to consider changing any of > these, I recommend that you take that up with your PMC representative on > the council. > > With the evolution of the simultaneous release to a rolling release > process, I half expected that the Planning Council might decide to require > explicit opt-in on a quarterly basis. I'm delighted that they've instead > decided to not raise the burden and instead just require a single annual > check in. > > I am thinking, though, that with the increase in frequency of releases, > it's time to rethink how we track participation in the release. We may > consider investing some energy in deriving this information from the > aggrcon files. This, of course, assumes that tracking this information is > actually valuable (and ignores that we have some projects that participate > in the simultaneous release, but do not contribute bits to the aggregate > repository). The explicit tracking has proven helpful for marketing > purposes, and helps those of us who work at a higher level than an > individual project. > > I don't know how to achieve all of this in an easier manner than a > once-per-year email. If you have suggestions for alternatives, please > connect with your PMC's Planning Council representative to have them bring > this discussion to the PC. > > Thanks, > > Wayne > -- > Wayne Beaton > Director of Open Source Projects > The Eclipse Foundation > > > _______________________________________________ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, > visithttps://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > <#m_-3488939442272430633_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Nick Boldt Principal Software Engineer, RHCSA Productization Lead :: JBoss Tools & Dev Studio IM: @nickboldt / @nboldt / http://nick.divbyzero.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> @ @redhatnews <https://twitter.com/redhatnews> Red Hat <https://www.facebook.com/RedHatInc> <https://www.facebook.com/RedHatInc> “The Only Thing That Is Constant Is Change” - Heraclitus
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
