You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficcontrol.apache.org by ocket 8888 <oc...@gmail.com> on 2021/09/08 15:09:40 UTC
Proposal: Remove "Spec" wiki pages
Two of these three pages have blueprint equivalents:
- Cache-Side Config Generation can be a link to
https://github.com/apache/trafficcontrol/blob/master/blueprints/ort-rewrite-unix-style.md
- Layered Profiles can be a link to
https://github.com/apache/trafficcontrol/pull/6095 (possibly updated to
https://github.com/apache/trafficcontrol/blob/master/blueprints/layered-profile.md
if/when merged)
Self-Service Change Integrity is a bit harder. It's not only just not
already a blueprint, but the information in the page arguably accounts for
more than ought to be covered by a single blueprint. Ideally, each of the
three changes the page argues for should, in my opinion, be its own
blueprint. What I propose, therefore, is doing exactly that. Opening three
blueprint PRs to account for the page's contents. These need not be merged.
While I do volunteer to make the blueprints, that could be a little awkward
given that I am not the champion of the enclosed ideas, nor even
necessarily a proponent. The alternatives would be for someone who is one
or both of those things to open blueprint PRs instead (most recent change
was Rob Butts, so I'm guessing him) or we could instead move the spec
verbatim to the GH wiki, which I can also do fairly easily.
Personally, I think blueprints make the most sense, and if/when we begin
earnest discussion on their contents and it becomes clear I'm not up to the
task/don't have the time, someone who is/does can just open a new PR using
the blueprint(s) I write as a basis, and my PR can be closed. But the last
edit to that page was a year and a half ago, so it's possible that won't be
for a while, or even that people would prefer to start from scratch by the
time that happens.
Re: Proposal: Remove "Spec" wiki pages
Posted by ocket 8888 <oc...@gmail.com>.
Done
On Thu, Sep 9, 2021 at 9:26 AM ocket 8888 <oc...@gmail.com> wrote:
> Alright, I would up just opening the blueprint as a blueprint PR instead
> of making it an issue. It's never too late to change that, so I figured why
> not. Its PR # (https://github.com/apache/trafficcontrol/pull/6180). I
> also opened https://github.com/apache/trafficcontrol/issues/6183 and
> https://github.com/apache/trafficcontrol/issues/6182 which all together
> should encompass the information expressed in the wiki page. People
> passionate about that page and its preservation should make sure it's all
> represented before I turn it into a link on, say, next Tuesday morning.
> Note that the edit history will preserve the contents after link-ification,
> so even if something slips through the cracks it won't be lost forever.
>
> On Wed, Sep 8, 2021 at 3:40 PM ocket 8888 <oc...@gmail.com> wrote:
>
>> On further investigation into works in progress and design issues open,
>> it's possible that the entire page could just become a link to
>> https://github.com/apache/trafficcontrol/projects/7 - but new issues
>> will need to be opened and added to that project to fully capture the
>> information of the wiki page. Seems like that might be the way to go
>> instead. I actually already finished writing up one of the three
>> blueprints, which can probably be almost literally copy/pasted into an
>> Issue body.
>>
>> On Wed, Sep 8, 2021 at 9:09 AM ocket 8888 <oc...@gmail.com> wrote:
>>
>>> Two of these three pages have blueprint equivalents:
>>>
>>> - Cache-Side Config Generation can be a link to
>>> https://github.com/apache/trafficcontrol/blob/master/blueprints/ort-rewrite-unix-style.md
>>> - Layered Profiles can be a link to
>>> https://github.com/apache/trafficcontrol/pull/6095 (possibly updated to
>>> https://github.com/apache/trafficcontrol/blob/master/blueprints/layered-profile.md
>>> if/when merged)
>>>
>>> Self-Service Change Integrity is a bit harder. It's not only just not
>>> already a blueprint, but the information in the page arguably accounts for
>>> more than ought to be covered by a single blueprint. Ideally, each of the
>>> three changes the page argues for should, in my opinion, be its own
>>> blueprint. What I propose, therefore, is doing exactly that. Opening three
>>> blueprint PRs to account for the page's contents. These need not be merged.
>>>
>>> While I do volunteer to make the blueprints, that could be a little
>>> awkward given that I am not the champion of the enclosed ideas, nor even
>>> necessarily a proponent. The alternatives would be for someone who is one
>>> or both of those things to open blueprint PRs instead (most recent change
>>> was Rob Butts, so I'm guessing him) or we could instead move the spec
>>> verbatim to the GH wiki, which I can also do fairly easily.
>>>
>>> Personally, I think blueprints make the most sense, and if/when we begin
>>> earnest discussion on their contents and it becomes clear I'm not up to the
>>> task/don't have the time, someone who is/does can just open a new PR using
>>> the blueprint(s) I write as a basis, and my PR can be closed. But the last
>>> edit to that page was a year and a half ago, so it's possible that won't be
>>> for a while, or even that people would prefer to start from scratch by the
>>> time that happens.
>>>
>>
Re: Proposal: Remove "Spec" wiki pages
Posted by ocket 8888 <oc...@gmail.com>.
Done
On Thu, Sep 9, 2021 at 9:26 AM ocket 8888 <oc...@gmail.com> wrote:
> Alright, I would up just opening the blueprint as a blueprint PR instead
> of making it an issue. It's never too late to change that, so I figured why
> not. Its PR # (https://github.com/apache/trafficcontrol/pull/6180). I
> also opened https://github.com/apache/trafficcontrol/issues/6183 and
> https://github.com/apache/trafficcontrol/issues/6182 which all together
> should encompass the information expressed in the wiki page. People
> passionate about that page and its preservation should make sure it's all
> represented before I turn it into a link on, say, next Tuesday morning.
> Note that the edit history will preserve the contents after link-ification,
> so even if something slips through the cracks it won't be lost forever.
>
> On Wed, Sep 8, 2021 at 3:40 PM ocket 8888 <oc...@gmail.com> wrote:
>
>> On further investigation into works in progress and design issues open,
>> it's possible that the entire page could just become a link to
>> https://github.com/apache/trafficcontrol/projects/7 - but new issues
>> will need to be opened and added to that project to fully capture the
>> information of the wiki page. Seems like that might be the way to go
>> instead. I actually already finished writing up one of the three
>> blueprints, which can probably be almost literally copy/pasted into an
>> Issue body.
>>
>> On Wed, Sep 8, 2021 at 9:09 AM ocket 8888 <oc...@gmail.com> wrote:
>>
>>> Two of these three pages have blueprint equivalents:
>>>
>>> - Cache-Side Config Generation can be a link to
>>> https://github.com/apache/trafficcontrol/blob/master/blueprints/ort-rewrite-unix-style.md
>>> - Layered Profiles can be a link to
>>> https://github.com/apache/trafficcontrol/pull/6095 (possibly updated to
>>> https://github.com/apache/trafficcontrol/blob/master/blueprints/layered-profile.md
>>> if/when merged)
>>>
>>> Self-Service Change Integrity is a bit harder. It's not only just not
>>> already a blueprint, but the information in the page arguably accounts for
>>> more than ought to be covered by a single blueprint. Ideally, each of the
>>> three changes the page argues for should, in my opinion, be its own
>>> blueprint. What I propose, therefore, is doing exactly that. Opening three
>>> blueprint PRs to account for the page's contents. These need not be merged.
>>>
>>> While I do volunteer to make the blueprints, that could be a little
>>> awkward given that I am not the champion of the enclosed ideas, nor even
>>> necessarily a proponent. The alternatives would be for someone who is one
>>> or both of those things to open blueprint PRs instead (most recent change
>>> was Rob Butts, so I'm guessing him) or we could instead move the spec
>>> verbatim to the GH wiki, which I can also do fairly easily.
>>>
>>> Personally, I think blueprints make the most sense, and if/when we begin
>>> earnest discussion on their contents and it becomes clear I'm not up to the
>>> task/don't have the time, someone who is/does can just open a new PR using
>>> the blueprint(s) I write as a basis, and my PR can be closed. But the last
>>> edit to that page was a year and a half ago, so it's possible that won't be
>>> for a while, or even that people would prefer to start from scratch by the
>>> time that happens.
>>>
>>
Re: Proposal: Remove "Spec" wiki pages
Posted by ocket 8888 <oc...@gmail.com>.
Alright, I would up just opening the blueprint as a blueprint PR instead of
making it an issue. It's never too late to change that, so I figured why
not. Its PR # (https://github.com/apache/trafficcontrol/pull/6180). I also
opened https://github.com/apache/trafficcontrol/issues/6183 and
https://github.com/apache/trafficcontrol/issues/6182 which all together
should encompass the information expressed in the wiki page. People
passionate about that page and its preservation should make sure it's all
represented before I turn it into a link on, say, next Tuesday morning.
Note that the edit history will preserve the contents after link-ification,
so even if something slips through the cracks it won't be lost forever.
On Wed, Sep 8, 2021 at 3:40 PM ocket 8888 <oc...@gmail.com> wrote:
> On further investigation into works in progress and design issues open,
> it's possible that the entire page could just become a link to
> https://github.com/apache/trafficcontrol/projects/7 - but new issues will
> need to be opened and added to that project to fully capture the
> information of the wiki page. Seems like that might be the way to go
> instead. I actually already finished writing up one of the three
> blueprints, which can probably be almost literally copy/pasted into an
> Issue body.
>
> On Wed, Sep 8, 2021 at 9:09 AM ocket 8888 <oc...@gmail.com> wrote:
>
>> Two of these three pages have blueprint equivalents:
>>
>> - Cache-Side Config Generation can be a link to
>> https://github.com/apache/trafficcontrol/blob/master/blueprints/ort-rewrite-unix-style.md
>> - Layered Profiles can be a link to
>> https://github.com/apache/trafficcontrol/pull/6095 (possibly updated to
>> https://github.com/apache/trafficcontrol/blob/master/blueprints/layered-profile.md
>> if/when merged)
>>
>> Self-Service Change Integrity is a bit harder. It's not only just not
>> already a blueprint, but the information in the page arguably accounts for
>> more than ought to be covered by a single blueprint. Ideally, each of the
>> three changes the page argues for should, in my opinion, be its own
>> blueprint. What I propose, therefore, is doing exactly that. Opening three
>> blueprint PRs to account for the page's contents. These need not be merged.
>>
>> While I do volunteer to make the blueprints, that could be a little
>> awkward given that I am not the champion of the enclosed ideas, nor even
>> necessarily a proponent. The alternatives would be for someone who is one
>> or both of those things to open blueprint PRs instead (most recent change
>> was Rob Butts, so I'm guessing him) or we could instead move the spec
>> verbatim to the GH wiki, which I can also do fairly easily.
>>
>> Personally, I think blueprints make the most sense, and if/when we begin
>> earnest discussion on their contents and it becomes clear I'm not up to the
>> task/don't have the time, someone who is/does can just open a new PR using
>> the blueprint(s) I write as a basis, and my PR can be closed. But the last
>> edit to that page was a year and a half ago, so it's possible that won't be
>> for a while, or even that people would prefer to start from scratch by the
>> time that happens.
>>
>
Re: Proposal: Remove "Spec" wiki pages
Posted by ocket 8888 <oc...@gmail.com>.
Alright, I would up just opening the blueprint as a blueprint PR instead of
making it an issue. It's never too late to change that, so I figured why
not. Its PR # (https://github.com/apache/trafficcontrol/pull/6180). I also
opened https://github.com/apache/trafficcontrol/issues/6183 and
https://github.com/apache/trafficcontrol/issues/6182 which all together
should encompass the information expressed in the wiki page. People
passionate about that page and its preservation should make sure it's all
represented before I turn it into a link on, say, next Tuesday morning.
Note that the edit history will preserve the contents after link-ification,
so even if something slips through the cracks it won't be lost forever.
On Wed, Sep 8, 2021 at 3:40 PM ocket 8888 <oc...@gmail.com> wrote:
> On further investigation into works in progress and design issues open,
> it's possible that the entire page could just become a link to
> https://github.com/apache/trafficcontrol/projects/7 - but new issues will
> need to be opened and added to that project to fully capture the
> information of the wiki page. Seems like that might be the way to go
> instead. I actually already finished writing up one of the three
> blueprints, which can probably be almost literally copy/pasted into an
> Issue body.
>
> On Wed, Sep 8, 2021 at 9:09 AM ocket 8888 <oc...@gmail.com> wrote:
>
>> Two of these three pages have blueprint equivalents:
>>
>> - Cache-Side Config Generation can be a link to
>> https://github.com/apache/trafficcontrol/blob/master/blueprints/ort-rewrite-unix-style.md
>> - Layered Profiles can be a link to
>> https://github.com/apache/trafficcontrol/pull/6095 (possibly updated to
>> https://github.com/apache/trafficcontrol/blob/master/blueprints/layered-profile.md
>> if/when merged)
>>
>> Self-Service Change Integrity is a bit harder. It's not only just not
>> already a blueprint, but the information in the page arguably accounts for
>> more than ought to be covered by a single blueprint. Ideally, each of the
>> three changes the page argues for should, in my opinion, be its own
>> blueprint. What I propose, therefore, is doing exactly that. Opening three
>> blueprint PRs to account for the page's contents. These need not be merged.
>>
>> While I do volunteer to make the blueprints, that could be a little
>> awkward given that I am not the champion of the enclosed ideas, nor even
>> necessarily a proponent. The alternatives would be for someone who is one
>> or both of those things to open blueprint PRs instead (most recent change
>> was Rob Butts, so I'm guessing him) or we could instead move the spec
>> verbatim to the GH wiki, which I can also do fairly easily.
>>
>> Personally, I think blueprints make the most sense, and if/when we begin
>> earnest discussion on their contents and it becomes clear I'm not up to the
>> task/don't have the time, someone who is/does can just open a new PR using
>> the blueprint(s) I write as a basis, and my PR can be closed. But the last
>> edit to that page was a year and a half ago, so it's possible that won't be
>> for a while, or even that people would prefer to start from scratch by the
>> time that happens.
>>
>
Re: Proposal: Remove "Spec" wiki pages
Posted by ocket 8888 <oc...@gmail.com>.
On further investigation into works in progress and design issues open,
it's possible that the entire page could just become a link to
https://github.com/apache/trafficcontrol/projects/7 - but new issues will
need to be opened and added to that project to fully capture the
information of the wiki page. Seems like that might be the way to go
instead. I actually already finished writing up one of the three
blueprints, which can probably be almost literally copy/pasted into an
Issue body.
On Wed, Sep 8, 2021 at 9:09 AM ocket 8888 <oc...@gmail.com> wrote:
> Two of these three pages have blueprint equivalents:
>
> - Cache-Side Config Generation can be a link to
> https://github.com/apache/trafficcontrol/blob/master/blueprints/ort-rewrite-unix-style.md
> - Layered Profiles can be a link to
> https://github.com/apache/trafficcontrol/pull/6095 (possibly updated to
> https://github.com/apache/trafficcontrol/blob/master/blueprints/layered-profile.md
> if/when merged)
>
> Self-Service Change Integrity is a bit harder. It's not only just not
> already a blueprint, but the information in the page arguably accounts for
> more than ought to be covered by a single blueprint. Ideally, each of the
> three changes the page argues for should, in my opinion, be its own
> blueprint. What I propose, therefore, is doing exactly that. Opening three
> blueprint PRs to account for the page's contents. These need not be merged.
>
> While I do volunteer to make the blueprints, that could be a little
> awkward given that I am not the champion of the enclosed ideas, nor even
> necessarily a proponent. The alternatives would be for someone who is one
> or both of those things to open blueprint PRs instead (most recent change
> was Rob Butts, so I'm guessing him) or we could instead move the spec
> verbatim to the GH wiki, which I can also do fairly easily.
>
> Personally, I think blueprints make the most sense, and if/when we begin
> earnest discussion on their contents and it becomes clear I'm not up to the
> task/don't have the time, someone who is/does can just open a new PR using
> the blueprint(s) I write as a basis, and my PR can be closed. But the last
> edit to that page was a year and a half ago, so it's possible that won't be
> for a while, or even that people would prefer to start from scratch by the
> time that happens.
>
Re: Proposal: Remove "Spec" wiki pages
Posted by ocket 8888 <oc...@gmail.com>.
On further investigation into works in progress and design issues open,
it's possible that the entire page could just become a link to
https://github.com/apache/trafficcontrol/projects/7 - but new issues will
need to be opened and added to that project to fully capture the
information of the wiki page. Seems like that might be the way to go
instead. I actually already finished writing up one of the three
blueprints, which can probably be almost literally copy/pasted into an
Issue body.
On Wed, Sep 8, 2021 at 9:09 AM ocket 8888 <oc...@gmail.com> wrote:
> Two of these three pages have blueprint equivalents:
>
> - Cache-Side Config Generation can be a link to
> https://github.com/apache/trafficcontrol/blob/master/blueprints/ort-rewrite-unix-style.md
> - Layered Profiles can be a link to
> https://github.com/apache/trafficcontrol/pull/6095 (possibly updated to
> https://github.com/apache/trafficcontrol/blob/master/blueprints/layered-profile.md
> if/when merged)
>
> Self-Service Change Integrity is a bit harder. It's not only just not
> already a blueprint, but the information in the page arguably accounts for
> more than ought to be covered by a single blueprint. Ideally, each of the
> three changes the page argues for should, in my opinion, be its own
> blueprint. What I propose, therefore, is doing exactly that. Opening three
> blueprint PRs to account for the page's contents. These need not be merged.
>
> While I do volunteer to make the blueprints, that could be a little
> awkward given that I am not the champion of the enclosed ideas, nor even
> necessarily a proponent. The alternatives would be for someone who is one
> or both of those things to open blueprint PRs instead (most recent change
> was Rob Butts, so I'm guessing him) or we could instead move the spec
> verbatim to the GH wiki, which I can also do fairly easily.
>
> Personally, I think blueprints make the most sense, and if/when we begin
> earnest discussion on their contents and it becomes clear I'm not up to the
> task/don't have the time, someone who is/does can just open a new PR using
> the blueprint(s) I write as a basis, and my PR can be closed. But the last
> edit to that page was a year and a half ago, so it's possible that won't be
> for a while, or even that people would prefer to start from scratch by the
> time that happens.
>