7:45 p.m.
= Proposed Self Contained Change: Let's Encrypt client now in Fedora =
https://fedoraproject.org/wiki/Changes/LetsEncrypt#Scope
Change owner(s):
* Nick Bebout <nb AT fedoraproject DOT org>
*James Hogarth <jhogarth AT fedoraproject DOT org>
* Nick Le Mouton <noodles AT fedoraproject DOT org>
The Let's Encrypt client is now packaged in Fedora. This will allow
Fedora users to easily install the Let's Encrypt client (letsencrypt)
and generate free SSL certificates for their websites (or other
services which use SSL)
== Detailed Description ==
The Let's Encrypt client is now packaged in Fedora. This will allow
Fedora users to easily install the Let's Encrypt client (letsencrypt)
and generate free SSL certificates for their websites (or other
services which use SSL)
== Scope ==
Proposal owners:
* To implement this Change
Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
List of deliverables: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
Trademark approval: N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
9:55 p.m.
On Mon, Feb 8, 2016 at 8:45 PM, Jan Kurik <jkurik(a)redhat.com> wrote:
= Proposed Self Contained Change: Let's Encrypt client now in
Fedora =
https://fedoraproject.org/wiki/Changes/LetsEncrypt#Scope
Why is this a proposed Change? Let's Encrypt was pushed out to *all*
currently supported Fedora releases, so of course it's naturally in
the next one. And aren't we supposed to *not* do stuff like this
anymore?
--
真実はいつも一つ！/ Always, there's only one truth!
6:09 a.m.
On Mon, Feb 8, 2016 at 8:45 PM, Jan Kurik <jkurik(a)redhat.com> wrote:
= Proposed Self Contained Change: Let's Encrypt client now in
Fedora =
https://fedoraproject.org/wiki/Changes/LetsEncrypt#Scope
Change owner(s):
* Nick Bebout <nb AT fedoraproject DOT org>
*James Hogarth <jhogarth AT fedoraproject DOT org>
* Nick Le Mouton <noodles AT fedoraproject DOT org>
The Let's Encrypt client is now packaged in Fedora. This will allow
Fedora users to easily install the Let's Encrypt client (letsencrypt)
and generate free SSL certificates for their websites (or other
services which use SSL)
== Detailed Description ==
The Let's Encrypt client is now packaged in Fedora. This will allow
Fedora users to easily install the Let's Encrypt client (letsencrypt)
and generate free SSL certificates for their websites (or other
services which use SSL)
== Scope ==
Proposal owners:
* To implement this Change
Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
List of deliverables: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
Trademark approval: N/A (not needed for this Change)
I see nothing here that would indicate this to be a Change. We don't
do Changes for new package adds. What about the addition of the Let's
Encrypt client makes this somehow a Change?
josh
6:28 a.m.
On Tue, Feb 9, 2016 at 11:32 AM, Jared K. Smith
<jsmith(a)fedoraproject.org> wrote:
On Mon, Feb 8, 2016 at 10:55 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> And aren't we supposed to *not* do stuff like this
> anymore?
If I had to guess, I'd say that this was proposed as an F24 change to help
it get publicity in the release notes, etc.
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.
josh
8:06 a.m.
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."
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:09 a.m.
On Tue, Feb 09, 2016 at 02:45:37AM +0100, Jan Kurik wrote:
Other developers: N/A (not a System Wide Change)
I'd love to see this extended to be a Fedora Server feature, and
possibly integrated with Cockpit. I remember some discussion about that
initially... where did that go?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:17 a.m.
On Wed, Feb 10, 2016 at 9:06 AM, Matthew Miller
<mattdm(a)fedoraproject.org> 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.
That led to people filing Features for whatever they thought was
important, which is fine but it overloaded the Feature process and put
hoops and hurdles in front of people where there shouldn't be. It
also diluted our marketing message to basically be a massive list of
all the Features, which all seemed equally important to the project.
An end user would read it and be very confused what Fedora was for.
So FESCo switched to Changes to focus solely on the technical impacts
of a _change_. People were supposed to be directed to docs and
marketing if they just wanted to highlight something they thought
would be neat. And now we've come full circle and here we are today.
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...
josh
8:34 a.m.
On 10 February 2016 at 14:09, Matthew Miller <mattdm(a)fedoraproject.org>
wrote:
On Tue, Feb 09, 2016 at 02:45:37AM +0100, Jan Kurik wrote:
> Other developers: N/A (not a System Wide Change)
I'd love to see this extended to be a Fedora Server feature, and
possibly integrated with Cockpit. I remember some discussion about that
initially... where did that go?
My child took my time so I couldn't drive it ;)
At the Server WG meeting that discussed it [1]
The decision was not to proceed with any cockpit work required as it was
hard to automate (honestly I'd debate this one but as I mentioned I was
unable to attend) and it required a publically visible server (with
appropriate DNS entries to point to it) making it moot for any internal
server deployment.
Given that, and a lack of time otherwise, I haven't pushed the WG for
anything more for now. It remains in beta at any rate at this stage so
there is a sane argument for how much effort to put into cockpit/rolekit
integration for now.
[1]
https://meetbot.fedoraproject.org/fedora-meeting-1/2015-12-15/serversig.2...
8:41 a.m.
On 10 February 2016 at 14:17, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Wed, Feb 10, 2016 at 9:06 AM, Matthew Miller
<mattdm(a)fedoraproject.org> 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?
>
> 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! ;)
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.
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.
8:57 a.m.
On Wed, Feb 10, 2016 at 9:41 AM, James Hogarth <james.hogarth(a)gmail.com> wrote:
On 10 February 2016 at 14:17, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>
> On Wed, Feb 10, 2016 at 9:06 AM, Matthew Miller
> <mattdm(a)fedoraproject.org> 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
9:27 a.m.
On 10 February 2016 at 14:57, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Wed, Feb 10, 2016 at 9:41 AM, James Hogarth
<james.hogarth(a)gmail.com>
wrote:
>>
> 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.
I was rather happy with the result.
> 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.
Err I don't know where you are getting this from ... I *did not* submit
this change ...
I'm the point of contact and one of the maintainers for Let's Encrypt but
I'm not the one that put together the wiki page.
As I pointed out I'm at best ambivalent about this being a valid change -
but we should probably have some mechanism to highlight new non-change
features.
Indeed though many (most?) Fedora changes won't affect future RHEL Mattdm
was the one over on those lists suggesting people pay attention to Fedora
ChangeSets for at least a rough heads up on what might be coming at some
point.
> 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.
Realistically I think LE has had enough publicity for now and given the
strong feelings would dismiss this from the F24 ChangeSet.
I would say it's taking it to the extreme to declare about all new packages
- most people won't care about the vast majority - but certain ones that
have a significant community interest around makes sense.
Regardless of potentially upcoming RHEL releases, the ability to highlight
non-change features in a Fedora release, outside of $random FM article,
sounds like it would be a worthwhile discussion to have on the marketing@
mailing list.
8:28 a.m.
I just deferred this Change as it is not needed anymore.
https://fedoraproject.org/wiki/Changes/LetsEncrypt
Regards,
Jan
On Wed, Feb 10, 2016 at 4:27 PM, James Hogarth <james.hogarth(a)gmail.com> wrote:
On 10 February 2016 at 14:57, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
>
> On Wed, Feb 10, 2016 at 9:41 AM, James Hogarth <james.hogarth(a)gmail.com>
> wrote:
> >>
> > 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.
>
I was rather happy with the result.
>
> > 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.
>
Err I don't know where you are getting this from ... I *did not* submit this
change ...
I'm the point of contact and one of the maintainers for Let's Encrypt but
I'm not the one that put together the wiki page.
As I pointed out I'm at best ambivalent about this being a valid change -
but we should probably have some mechanism to highlight new non-change
features.
Indeed though many (most?) Fedora changes won't affect future RHEL Mattdm
was the one over on those lists suggesting people pay attention to Fedora
ChangeSets for at least a rough heads up on what might be coming at some
point.
>
> > 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.
Realistically I think LE has had enough publicity for now and given the
strong feelings would dismiss this from the F24 ChangeSet.
I would say it's taking it to the extreme to declare about all new packages
- most people won't care about the vast majority - but certain ones that
have a significant community interest around makes sense.
Regardless of potentially upcoming RHEL releases, the ability to highlight
non-change features in a Fedora release, outside of $random FM article,
sounds like it would be a worthwhile discussion to have on the marketing@
mailing list.
--
devel mailing list
devel(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
9:16 a.m.
On Feb 10, 2016 6:29 AM, "Josh Boyer" <jwboyer(a)fedoraproject.org> wrote:
On Tue, Feb 9, 2016 at 11:32 AM, Jared K. Smith
<jsmith(a)fedoraproject.org> wrote:
>
> On Mon, Feb 8, 2016 at 10:55 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
>>
>> And aren't we supposed to *not* do stuff like this
>> anymore?
>
>
>
> If I had to guess, I'd say that this was proposed as an F24 change to
help
> it get publicity in the release notes, etc.
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.
josh
--
FWIW, to get attention for a new package in the release notes process, you
can simply set the review ticket's fedora_requires_release_notes flag to ?.
--Pete
12:23 p.m.
On 02/10/2016 09:06 AM, Matthew Miller wrote:
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."
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.
This is very helpful to marketing. I do use the Changes, and it's...
unusual to say the least for developers to roll up to marketing and ask
specifically for their feature/change to be promoted.
I don't see how this is harmful.
Best,
jzb
--
Joe Brockmeier | Community Team, OSAS
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb | http://dissociatedpress.net/
3004
days inactive
3011
days old
14 comments
8 participants
participants (8)
-
James Hogarth -
Jan Kurik -
Jared K. Smith -
Joe Brockmeier -
Josh Boyer -
Matthew Miller -
Neal Gompa -
Pete Travis