All of lore.kernel.org
 help / color / mirror / Atom feed
* ref-manual: reverse the order of migration guides?
@ 2021-04-13 18:03 Michael Opdenacker
  2021-04-13 19:40 ` [docs] " Richard Purdie
  2021-04-14  0:15 ` Paul Eggleton
  0 siblings, 2 replies; 8+ messages in thread
From: Michael Opdenacker @ 2021-04-13 18:03 UTC (permalink / raw)
  To: YP docs mailing list

Greetings,

Wouldn't it make sense to reverse the order of migration guides in the
reference manual
(https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#migration)?

I guess it would be easier to start mentioning the migration path from
the most recent release, as version 1.3 looks ancient.

Would it make sense? If so, it's easy to propose a patch...

Thanks in advance,

Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [docs] ref-manual: reverse the order of migration guides?
  2021-04-13 18:03 ref-manual: reverse the order of migration guides? Michael Opdenacker
@ 2021-04-13 19:40 ` Richard Purdie
  2021-04-13 19:49   ` Robert P. J. Day
  2021-04-14  0:15 ` Paul Eggleton
  1 sibling, 1 reply; 8+ messages in thread
From: Richard Purdie @ 2021-04-13 19:40 UTC (permalink / raw)
  To: Michael Opdenacker, YP docs mailing list

On Tue, 2021-04-13 at 20:03 +0200, Michael Opdenacker wrote:
> Greetings,
> 
> Wouldn't it make sense to reverse the order of migration guides in the
> reference manual
> (https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#migration)?
> 
> I guess it would be easier to start mentioning the migration path from
> the most recent release, as version 1.3 looks ancient.
> 
> Would it make sense? If so, it's easy to propose a patch...

Yes, I think it would. When we made the migration to sphinx, I took the decision
to split these into their own files. This is a next logical step from that.

Cheers,

Richard


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [docs] ref-manual: reverse the order of migration guides?
  2021-04-13 19:40 ` [docs] " Richard Purdie
@ 2021-04-13 19:49   ` Robert P. J. Day
  0 siblings, 0 replies; 8+ messages in thread
From: Robert P. J. Day @ 2021-04-13 19:49 UTC (permalink / raw)
  To: docs


Quoting Richard Purdie <richard.purdie@linuxfoundation.org>:

> On Tue, 2021-04-13 at 20:03 +0200, Michael Opdenacker wrote:
>> Greetings,
>>
>> Wouldn't it make sense to reverse the order of migration guides in the
>> reference manual
>> (https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#migration)?
>>
>> I guess it would be easier to start mentioning the migration path from
>> the most recent release, as version 1.3 looks ancient.
>>
>> Would it make sense? If so, it's easy to propose a patch...
>
> Yes, I think it would. When we made the migration to sphinx, I took  
> the decision
> to split these into their own files. This is a next logical step from that.

   i'd go for moving all the migration stuff into its own manual ...
the reference manual is chock full as it is, there's no point making
it even larger with material that new users won't care about.

rday




^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [docs] ref-manual: reverse the order of migration guides?
  2021-04-13 18:03 ref-manual: reverse the order of migration guides? Michael Opdenacker
  2021-04-13 19:40 ` [docs] " Richard Purdie
@ 2021-04-14  0:15 ` Paul Eggleton
  2021-04-14  5:33   ` Nicolas Dechesne
  1 sibling, 1 reply; 8+ messages in thread
From: Paul Eggleton @ 2021-04-14  0:15 UTC (permalink / raw)
  To: YP docs mailing list
  Cc: Michael Opdenacker, Robert P. J. Day, Tummalapalli, Vineela,
	Richard Purdie

Hi Michael

On Wednesday, 14 April 2021 06:03:26 NZST Michael Opdenacker wrote:
> Wouldn't it make sense to reverse the order of migration guides in the
> reference manual
> (https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#migration)
> ?
> 
> I guess it would be easier to start mentioning the migration path from
> the most recent release, as version 1.3 looks ancient.
> 
> Would it make sense? If so, it's easy to propose a patch...

I guess the thinking was that you would start at the point in the 
documentation where you are currently at and then follow it downwards to the 
current version. Whether that's the most logical I'm not sure, but if we're 
changing it we should give some thought to how it will be used. People do 
often go a while between upgrades, but I'll definitely agree 1.3 is much 
further back than most people would need.

Robert suggests moving it out, I'm wondering if it's worth considering going a 
step further and turning our release notes into a proper document, to which 
this content would be added - I've often felt that the current text-only 
format is a bit restrictive. That would mean there would be a separate 
document per release, which is how many other software packages do it (e.g. 
Django). However, I'm not sure if that would cause us too much overhead or 
hassle with the other places where we currently post the release notes e.g. 
announcements on the mailing list - thoughts? (For clarity I wouldn't propose 
changing this until the next release.)

Cheers
Paul



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [docs] ref-manual: reverse the order of migration guides?
  2021-04-14  0:15 ` Paul Eggleton
@ 2021-04-14  5:33   ` Nicolas Dechesne
  2021-04-14  7:34     ` Michael Opdenacker
  0 siblings, 1 reply; 8+ messages in thread
From: Nicolas Dechesne @ 2021-04-14  5:33 UTC (permalink / raw)
  To: Paul Eggleton
  Cc: YP docs mailing list, Michael Opdenacker, Robert P. J. Day,
	Tummalapalli, Vineela, Richard Purdie

[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]

On Wed, Apr 14, 2021 at 2:15 AM Paul Eggleton <
bluelightning@bluelightning.org> wrote:

> Hi Michael
>
> On Wednesday, 14 April 2021 06:03:26 NZST Michael Opdenacker wrote:
> > Wouldn't it make sense to reverse the order of migration guides in the
> > reference manual
> > (
> https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#migration
> )
> > ?
> >
> > I guess it would be easier to start mentioning the migration path from
> > the most recent release, as version 1.3 looks ancient.
> >
> > Would it make sense? If so, it's easy to propose a patch...
>
> I guess the thinking was that you would start at the point in the
> documentation where you are currently at and then follow it downwards to
> the
> current version. Whether that's the most logical I'm not sure, but if
> we're
> changing it we should give some thought to how it will be used. People do
> often go a while between upgrades, but I'll definitely agree 1.3 is much
> further back than most people would need.
>
> Robert suggests moving it out, I'm wondering if it's worth considering
> going a
> step further and turning our release notes into a proper document, to
> which
> this content would be added - I've often felt that the current text-only
> format is a bit restrictive. That would mean there would be a separate
> document per release, which is how many other software packages do it
> (e.g.
> Django). However, I'm not sure if that would cause us too much overhead or
> hassle with the other places where we currently post the release notes
> e.g.
> announcements on the mailing list - thoughts? (For clarity I wouldn't
> propose
> changing this until the next release.)
>

I have had this thought already, and like it! Especially now that we have a
'unified' doc website, having a 'release notes' manual/section in the left
side navigation bar would be good. Here is an example I have seen with
another project:
https://projectacrn.github.io/latest/release_notes/index.html


>
> Cheers
> Paul
>
>
>
> 
>
>

[-- Attachment #2: Type: text/html, Size: 2896 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [docs] ref-manual: reverse the order of migration guides?
  2021-04-14  5:33   ` Nicolas Dechesne
@ 2021-04-14  7:34     ` Michael Opdenacker
  0 siblings, 0 replies; 8+ messages in thread
From: Michael Opdenacker @ 2021-04-14  7:34 UTC (permalink / raw)
  To: Nicolas Dechesne, Paul Eggleton
  Cc: YP docs mailing list, Robert P. J. Day, Tummalapalli, Vineela,
	Richard Purdie

Greetings,

On 4/14/21 7:33 AM, Nicolas Dechesne wrote:
>
>
> On Wed, Apr 14, 2021 at 2:15 AM Paul Eggleton
> <bluelightning@bluelightning.org
> <mailto:bluelightning@bluelightning.org>> wrote:
>
>
>
>     I guess the thinking was that you would start at the point in the
>     documentation where you are currently at and then follow it
>     downwards to the
>     current version. Whether that's the most logical I'm not sure, but
>     if we're
>     changing it we should give some thought to how it will be used.
>     People do
>     often go a while between upgrades, but I'll definitely agree 1.3
>     is much
>     further back than most people would need.
>
>     Robert suggests moving it out, I'm wondering if it's worth
>     considering going a
>     step further and turning our release notes into a proper document,
>     to which
>     this content would be added - I've often felt that the current
>     text-only
>     format is a bit restrictive. That would mean there would be a
>     separate
>     document per release, which is how many other software packages do
>     it (e.g.
>     Django). However, I'm not sure if that would cause us too much
>     overhead or
>     hassle with the other places where we currently post the release
>     notes e.g.
>     announcements on the mailing list - thoughts? (For clarity I
>     wouldn't propose
>     changing this until the next release.)
>
>
> I have had this thought already, and like it! Especially now that we
> have a 'unified' doc website, having a 'release notes' manual/section
> in the left side navigation bar would be good. Here is an example I
> have seen with another project:
> https://projectacrn.github.io/latest/release_notes/index.html
> <https://projectacrn.github.io/latest/release_notes/index.html>


I definitely vote for this. This would make our documentation much
easier to use.

Cheers,

Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: ref-manual: reverse the order of migration guides?
  2021-04-13 18:00 Michael Opdenacker
@ 2021-04-13 18:02 ` Michael Opdenacker
  0 siblings, 0 replies; 8+ messages in thread
From: Michael Opdenacker @ 2021-04-13 18:02 UTC (permalink / raw)
  To: yocto

Oops, sent to the wrong list (meant to use the "docs" list). You can
remove if this list is moderated.

Apologies

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


^ permalink raw reply	[flat|nested] 8+ messages in thread

* ref-manual: reverse the order of migration guides?
@ 2021-04-13 18:00 Michael Opdenacker
  2021-04-13 18:02 ` Michael Opdenacker
  0 siblings, 1 reply; 8+ messages in thread
From: Michael Opdenacker @ 2021-04-13 18:00 UTC (permalink / raw)
  To: yocto

Greetings,

Wouldn't it make sense to reverse the order of migration guides in the
reference manual
(https://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#migration)?

I guess it would be easier to start mentioning the migration path from
the most recent release, as version 1.3 looks ancient.

Would it make sense? If so, it's easy to propose a patch...

Thanks in advance,

Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-04-14  7:34 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-13 18:03 ref-manual: reverse the order of migration guides? Michael Opdenacker
2021-04-13 19:40 ` [docs] " Richard Purdie
2021-04-13 19:49   ` Robert P. J. Day
2021-04-14  0:15 ` Paul Eggleton
2021-04-14  5:33   ` Nicolas Dechesne
2021-04-14  7:34     ` Michael Opdenacker
  -- strict thread matches above, loose matches on Subject: below --
2021-04-13 18:00 Michael Opdenacker
2021-04-13 18:02 ` Michael Opdenacker

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.