On Wed, Feb 10, 2016 at 9:41 AM, James Hogarth <james.hogarth@xxxxxxxxx> wrote: > > > On 10 February 2016 at 14:17, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: >> >> On Wed, Feb 10, 2016 at 9:06 AM, Matthew Miller >> <mattdm@xxxxxxxxxxxxxxxxx> wrote: >> > On Wed, Feb 10, 2016 at 07:28:52AM -0500, Josh Boyer wrote: >> >> Changes are not used for that purpose. It is expressly the reason we >> >> decided to stop calling them Features. Changes focus on the technical >> >> content and impact for communication with Fedora developers. There's >> >> nothing in this one that other developers really need to know about on >> >> a project wide scale. >> >> >> >> If someone wants to market something, they should be working with the >> >> docs and marketing teams directly. >> > >> > Hmmm. I'm not sure this is true -- or if it is, we might need something >> > else. Marketing still uses the changes as a primary communication >> > channel for this kind of thing. The Changes Policy page says "Public >> > announcement of a new self contained change promotes cooperation on the >> > change, and extends its visibility." >> >> Sigh, really? Somewhere in the intervening years we've regressed then. >> >> The problem we originally addressed was that marketing would scroll >> through the Features and randomly pick some subset to promote the >> upcoming release. It was terrible. They'd choose things like "new >> update of the D programming language" because they didn't know what >> that meant or if it was important. FESCo was similarly terrible at >> figuring out which Features were neat marketing material. Some were >> obvious, but most were not. >> > > We should have something better to track highlighted features I agree. TO be > honest I'm ambivalent at best myself over whether to list this as a change. > > As pointed out it's backported to F23 as we didn't want to wait till F24 to > get it out there with many people asking about it in the community. > > Perhaps this should just serve to spur discussion on a better way to handle > this type of thing? Sure. >> > >> > Honestly, I'm more than a little unhappy to be coming down on people >> > for attempting to follow formal procedures and increase communication >> > and cooperation. >> >> I'm not coming down on anyone. I didn't say it wasn't important. I >> didn't say we shouldn't do this. I'm asking why this is different >> than any other new package addition we do in the distribution. I've >> not gotten an answer at all. If the answer is "marketing" then we >> should help them talk to marketing... >> > > Marketing are aware the package exists ... I worked with them on the Fedora > Magazine article(s) after all ... even got a >5000 view badge for it! ;) Fantastic. > Putting on my #centos community hat though ... > > Recently there was an uproar in mailing lists there and we told people to > pay attention to Fedora ChangeSets for a loose indication on things to be > aware of coming up. So you took a process that originally already had problems and added more problems by telling people to use it for things it wasn't meant for? :) Seriously, I understand the motivation there but Changes is not the place to pay attention to things from a CentOS perspective. Not every Change will wind up in RHEL, so it is already misleading. Further, given the lifecycles, a Change that lands in one Fedora release may be superseded by one in a later release. > If new packages/technology aren't to be mentioned and only changes to > existing technology that may affect $developer are we do need a better way > of exposing new things that are not changes. Yes. New packages land in Fedora all the time. We don't want to require them to file a Change simply because someone in some other project might be interested in it. It's too much process. If we need cross-project collaboration on things that will either be _in_ RHEL for sure, or things that CentOS wants/needs, that is a totally separate discussion. One that is certainly worth having. josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
