* CDS process @ 2015-02-05 13:50 Sage Weil 2015-02-05 14:26 ` John Spray 2015-02-05 15:36 ` Josh Durgin 0 siblings, 2 replies; 6+ messages in thread From: Sage Weil @ 2015-02-05 13:50 UTC (permalink / raw) To: pmcgarry, ceph-devel I wonder if we should simplify the cds workflow a bit to go straight to an etherpad outline of the blueprint instead of the wiki blueprint doc. I find it a bit disorienting to be flipping between the two, and after the fact find it frustrating that there isn't a single reference to go back to for the outcome of the session (you have to look at both the pad and the bp). Perhaps just using the pad from the get-go will streamline things a bit and make it a little more lightweight? What does everyone think? sage ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CDS process 2015-02-05 13:50 CDS process Sage Weil @ 2015-02-05 14:26 ` John Spray 2015-02-05 15:36 ` Josh Durgin 1 sibling, 0 replies; 6+ messages in thread From: John Spray @ 2015-02-05 14:26 UTC (permalink / raw) To: Sage Weil; +Cc: Patrick McGarry, Ceph Development +1 I've always found the sometimes-populated-sometimes-not blueprint docs confusing. John On Thu, Feb 5, 2015 at 2:50 PM, Sage Weil <sweil@redhat.com> wrote: > I wonder if we should simplify the cds workflow a bit to go straight to an > etherpad outline of the blueprint instead of the wiki blueprint doc. I > find it a bit disorienting to be flipping between the two, and after the > fact find it frustrating that there isn't a single reference to go back to > for the outcome of the session (you have to look at both the pad and the > bp). > > Perhaps just using the pad from the get-go will streamline things a bit > and make it a little more lightweight? What does everyone think? > > sage > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CDS process 2015-02-05 13:50 CDS process Sage Weil 2015-02-05 14:26 ` John Spray @ 2015-02-05 15:36 ` Josh Durgin [not found] ` <CAAZbbf2dpsj1MuzRY1REvF1Ow=UhX9HZhtO7=Hro_E7uiWRVtw@mail.gmail.com> 1 sibling, 1 reply; 6+ messages in thread From: Josh Durgin @ 2015-02-05 15:36 UTC (permalink / raw) To: Sage Weil, pmcgarry, ceph-devel On 02/05/2015 02:50 PM, Sage Weil wrote: > I wonder if we should simplify the cds workflow a bit to go straight to an > etherpad outline of the blueprint instead of the wiki blueprint doc. I > find it a bit disorienting to be flipping between the two, and after the > fact find it frustrating that there isn't a single reference to go back to > for the outcome of the session (you have to look at both the pad and the > bp). > > Perhaps just using the pad from the get-go will streamline things a bit > and make it a little more lightweight? What does everyone think? Sounds good to me. I've also wished there were a single location to capture a session; searching through the wiki for etherpads that aren't linked from the blueprint is a pain. Josh ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <CAAZbbf2dpsj1MuzRY1REvF1Ow=UhX9HZhtO7=Hro_E7uiWRVtw@mail.gmail.com>]
* Re: CDS process [not found] ` <CAAZbbf2dpsj1MuzRY1REvF1Ow=UhX9HZhtO7=Hro_E7uiWRVtw@mail.gmail.com> @ 2015-02-17 1:42 ` Sage Weil 2015-02-17 16:24 ` Patrick McGarry 0 siblings, 1 reply; 6+ messages in thread From: Sage Weil @ 2015-02-17 1:42 UTC (permalink / raw) To: Patrick McGarry; +Cc: Josh Durgin, Ceph Devel [-- Attachment #1: Type: TEXT/PLAIN, Size: 1998 bytes --] On Mon, 16 Feb 2015, Patrick McGarry wrote: > I think I'm going to take this forward in baby steps. I'm going to collect > blueprints via the normal pathway and then just manually capture the data in > ether pads when I populate the schedule. For J I'll just direct people > directly to ether pads (assuming there is no major objection). Are you worried about the documented workflow and tooling in the wiki, or just want to start with small changes to the process? It's also the copying part and most-empty blueprints that I suspect we can avoid without loss of value. I'm curious if we go super-light on the tooling if we'll find that there are parts we miss or not. Any other thoughts? sage > > On Thu, Feb 5, 2015 at 10:36 AM, Josh Durgin <josh.durgin@inktank.com> > wrote: > On 02/05/2015 02:50 PM, Sage Weil wrote: > I wonder if we should simplify the cds workflow a > bit to go straight to an > etherpad outline of the blueprint instead of the > wiki blueprint doc. I > find it a bit disorienting to be flipping between > the two, and after the > fact find it frustrating that there isn't a single > reference to go back to > for the outcome of the session (you have to look at > both the pad and the > bp). > > Perhaps just using the pad from the get-go will > streamline things a bit > and make it a little more lightweight? What does > everyone think? > > > Sounds good to me. I've also wished there were a single location to > capture a session; searching through the wiki for etherpads that > aren't linked from the blueprint is a pain. > > Josh > > > > > -- > > Best Regards, > > Patrick McGarry > Director Ceph Community || Red Hat > http://ceph.com || http://community.redhat.com > @scuttlemonkey || @ceph > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CDS process 2015-02-17 1:42 ` Sage Weil @ 2015-02-17 16:24 ` Patrick McGarry 2015-02-17 16:42 ` Haomai Wang 0 siblings, 1 reply; 6+ messages in thread From: Patrick McGarry @ 2015-02-17 16:24 UTC (permalink / raw) To: Sage Weil; +Cc: Josh Durgin, Ceph Devel Mostly I just want to do small incremental changes to the process, especially since it's happening so close to the summit. The only thing that I'll miss with an etherpad-only workflow is the notification on creations/edits, but I'll survive. I think it's just a matter of enforcing the use of blueprints, regardless of where they live. On Mon, Feb 16, 2015 at 8:42 PM, Sage Weil <sage@newdream.net> wrote: > On Mon, 16 Feb 2015, Patrick McGarry wrote: >> I think I'm going to take this forward in baby steps. I'm going to collect >> blueprints via the normal pathway and then just manually capture the data in >> ether pads when I populate the schedule. For J I'll just direct people >> directly to ether pads (assuming there is no major objection). > > Are you worried about the documented workflow and tooling in the wiki, or > just want to start with small changes to the process? It's also the > copying part and most-empty blueprints that I suspect we can avoid without > loss of value. I'm curious if we go super-light on the tooling if we'll > find that there are parts we miss or not. > > Any other thoughts? > sage > > >> >> On Thu, Feb 5, 2015 at 10:36 AM, Josh Durgin <josh.durgin@inktank.com> >> wrote: >> On 02/05/2015 02:50 PM, Sage Weil wrote: >> I wonder if we should simplify the cds workflow a >> bit to go straight to an >> etherpad outline of the blueprint instead of the >> wiki blueprint doc. I >> find it a bit disorienting to be flipping between >> the two, and after the >> fact find it frustrating that there isn't a single >> reference to go back to >> for the outcome of the session (you have to look at >> both the pad and the >> bp). >> >> Perhaps just using the pad from the get-go will >> streamline things a bit >> and make it a little more lightweight? What does >> everyone think? >> >> >> Sounds good to me. I've also wished there were a single location to >> capture a session; searching through the wiki for etherpads that >> aren't linked from the blueprint is a pain. >> >> Josh >> >> >> >> >> -- >> >> Best Regards, >> >> Patrick McGarry >> Director Ceph Community || Red Hat >> http://ceph.com || http://community.redhat.com >> @scuttlemonkey || @ceph >> >> -- Best Regards, Patrick McGarry Director Ceph Community || Red Hat http://ceph.com || http://community.redhat.com @scuttlemonkey || @ceph ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CDS process 2015-02-17 16:24 ` Patrick McGarry @ 2015-02-17 16:42 ` Haomai Wang 0 siblings, 0 replies; 6+ messages in thread From: Haomai Wang @ 2015-02-17 16:42 UTC (permalink / raw) To: Patrick McGarry; +Cc: Sage Weil, Josh Durgin, Ceph Devel It seemed wiki is better for recording bp and other users(not dev?) can have a nice look. If we put all in pad, it may be mess for different bp? We have some facts: 1. bp needed to be formatted and have a unified view for viewers 2. heavily changes will be applied during CDS mainly 3. latter(after CDS) changes to *bp* needed to be notify So maybe we can register a bp on wiki at first, then heavily changes will happen during CDS and also write in pad. After each session, we need to rewrite(copy?) back to wiki. This way can be a tradeoff between pad and wiki? On Wed, Feb 18, 2015 at 12:24 AM, Patrick McGarry <pmcgarry@redhat.com> wrote: > Mostly I just want to do small incremental changes to the process, > especially since it's happening so close to the summit. > > The only thing that I'll miss with an etherpad-only workflow is the > notification on creations/edits, but I'll survive. I think it's just a > matter of enforcing the use of blueprints, regardless of where they > live. > > > > On Mon, Feb 16, 2015 at 8:42 PM, Sage Weil <sage@newdream.net> wrote: >> On Mon, 16 Feb 2015, Patrick McGarry wrote: >>> I think I'm going to take this forward in baby steps. I'm going to collect >>> blueprints via the normal pathway and then just manually capture the data in >>> ether pads when I populate the schedule. For J I'll just direct people >>> directly to ether pads (assuming there is no major objection). >> >> Are you worried about the documented workflow and tooling in the wiki, or >> just want to start with small changes to the process? It's also the >> copying part and most-empty blueprints that I suspect we can avoid without >> loss of value. I'm curious if we go super-light on the tooling if we'll >> find that there are parts we miss or not. >> >> Any other thoughts? >> sage >> >> >>> >>> On Thu, Feb 5, 2015 at 10:36 AM, Josh Durgin <josh.durgin@inktank.com> >>> wrote: >>> On 02/05/2015 02:50 PM, Sage Weil wrote: >>> I wonder if we should simplify the cds workflow a >>> bit to go straight to an >>> etherpad outline of the blueprint instead of the >>> wiki blueprint doc. I >>> find it a bit disorienting to be flipping between >>> the two, and after the >>> fact find it frustrating that there isn't a single >>> reference to go back to >>> for the outcome of the session (you have to look at >>> both the pad and the >>> bp). >>> >>> Perhaps just using the pad from the get-go will >>> streamline things a bit >>> and make it a little more lightweight? What does >>> everyone think? >>> >>> >>> Sounds good to me. I've also wished there were a single location to >>> capture a session; searching through the wiki for etherpads that >>> aren't linked from the blueprint is a pain. >>> >>> Josh >>> >>> >>> >>> >>> -- >>> >>> Best Regards, >>> >>> Patrick McGarry >>> Director Ceph Community || Red Hat >>> http://ceph.com || http://community.redhat.com >>> @scuttlemonkey || @ceph >>> >>> > > > > -- > > Best Regards, > > Patrick McGarry > Director Ceph Community || Red Hat > http://ceph.com || http://community.redhat.com > @scuttlemonkey || @ceph > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards, Wheat ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-02-17 16:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-05 13:50 CDS process Sage Weil
2015-02-05 14:26 ` John Spray
2015-02-05 15:36 ` Josh Durgin
[not found] ` <CAAZbbf2dpsj1MuzRY1REvF1Ow=UhX9HZhtO7=Hro_E7uiWRVtw@mail.gmail.com>
2015-02-17 1:42 ` Sage Weil
2015-02-17 16:24 ` Patrick McGarry
2015-02-17 16:42 ` Haomai Wang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.