Thanks for raising this Colin, the redirection has been a source of
frustration among friends and users on IRC.
On Mon, Oct 14, 2019 at 12:13:30PM +0100, Colin Watson wrote:
> buried deep in a wall of text on
> https://help.ubuntu.com/community/ReportingBugs. I find it very easy to
> see how people could read that multiple times and still miss it (indeed,
> over the years I've spoken to several people who have done exactly
> that).
It takes me a long time to find this every time I ask a friend to file a
bug for a problem they've found. Since I never see this myself, even finding
the right page takes a long time. (The very slow wiki server is an added
frustration.)
> == Suggestions ==
> * Rearrange the UX for reporting bugs on Ubuntu as a non-member of
> ~ubuntu-bugcontrol so that it presents the reference to ReportingBugs
> and the advice to use ubuntu-bug in a way that's hard to ignore but
> that can still be skipped. For example, much like the way we
> currently have a first step of the bug-filing form that presents
> people with possible duplicates, we could have another step that
> guides people towards using ubuntu-bug; they'd only get the full form
> if they skip that as well.
>
> (I'd suggest that a good test for whether this has been done well is
> if we can tolerate removing the special case for members of
> ~ubuntu-bugcontrol. It isn't a great sign when we have to exempt
> developers from something partly because it's too annoying.)
I like this. (Though I suspect the 'possible duplicates' behaviour
encourages users to comment on long-past bug reports. A new bug report
is almost always preferable to a comment on an ancient bug report.)
Anyway, having some way to sidestep the interruption while in the flow
of using the website would be very welcome.
> * Remove the redirection entirely from /ubuntu/+source/PACKAGE/+filebug
> pages (though retaining the bug reporting guidelines displayed
> there), keeping it only on /ubuntu/+filebug. This would still serve
> the purpose of stemming the flow of low-value bug reports that don't
> specify a package name, while making it easier for people who at
> least have some idea which bit of software is going wrong.
I don't have good visibility on how many low-quality bug reports we
get via the different interfaces, and no idea at all what the ratio of
"hypothetically good" vs "hypothetically bad" bug reports would be IF
people hadn't been deterred by the redirections.
I see low-quality bug reports filed against random source packages all
the time.
I rarely see bug reports of any sort against /ubuntu/ but they don't feel
significantly worse.
My suspicion is this would move some low-quality bug reports
to random source packages. "Just file all your bugs on
/ubuntu/+source/bash/+filebug" kind of cargo-culting.
Thanks
Tuesday, 15 October 2019
Re: Reconsidering Ubuntu bug-filing redirection
On Mon, Oct 14, 2019 at 12:13:30PM +0100, Colin Watson wrote:
> About ten years ago [1] [2], Launchpad was changed so that, if people
> try to file a bug on Ubuntu directly via the web, then they're instead
> redirected to https://help.ubuntu.com/community/ReportingBugs which
> explains how to file a bug using the appropriate tools. Some way down,
> this explains how to file bugs manually and bypass this redirection.
>
> At the time, this change was described as an experiment. I think it's
> worth having a look at this and seeing if we can tweak it to reduce some
> sources of frustration.
>
> I think we could consider other approaches in the Launchpad UI to give
> people a nudge towards good local bug-reporting tools while being
> slightly less user-hostile to people who know what they're doing about
> bugs in general but not about Ubuntu's processes. I have two specific
> independent ideas that I'd like to submit for consideration:
>
> * Rearrange the UX for reporting bugs on Ubuntu as a non-member of
> ~ubuntu-bugcontrol so that it presents the reference to ReportingBugs
> and the advice to use ubuntu-bug in a way that's hard to ignore but
> that can still be skipped.
> About ten years ago [1] [2], Launchpad was changed so that, if people
> try to file a bug on Ubuntu directly via the web, then they're instead
> redirected to https://help.ubuntu.com/community/ReportingBugs which
> explains how to file a bug using the appropriate tools. Some way down,
> this explains how to file bugs manually and bypass this redirection.
>
> At the time, this change was described as an experiment. I think it's
> worth having a look at this and seeing if we can tweak it to reduce some
> sources of frustration.
>
> I think we could consider other approaches in the Launchpad UI to give
> people a nudge towards good local bug-reporting tools while being
> slightly less user-hostile to people who know what they're doing about
> bugs in general but not about Ubuntu's processes. I have two specific
> independent ideas that I'd like to submit for consideration:
>
> * Rearrange the UX for reporting bugs on Ubuntu as a non-member of
> ~ubuntu-bugcontrol so that it presents the reference to ReportingBugs
> and the advice to use ubuntu-bug in a way that's hard to ignore but
> that can still be skipped.
Back in 2010 there was some discussion on this issue, and Deryck Hodge
had a proposal to make the UX follow a "Your bug is X% complete" style,
maybe conceptually similar to this suggestion, which was captured as a
"Bugs Q&A" story:
https://dev.launchpad.net/Bugs/BugQ%26A
Fairly rough concept there, but apparently was included for the LP 4.0
roadmap (https://dev.launchpad.net/VersionFourDotO/Stories).
Bryce
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Supporting LZ4 as initramfs compressor
On Tue, Oct 15, 2019 at 05:18:47PM +0100, Dimitri John Ledkov wrote:
> On Tue, 15 Oct 2019 at 11:13, Dimitri John Ledkov <xnox@ubuntu.com> wrote:
> >
> > On Wed, 5 Jun 2019 at 21:25, Dimitri John Ledkov <xnox@ubuntu.com> wrote:
> > >
> > > On Wed, 5 Jun 2019 at 19:59, Steve Langasek <steve.langasek@ubuntu.com> wrote:
> > > >
> > > > Hi Dimitri,
> > > >
> > > > One point here:
> > > >
> > > > On Wed, Jun 05, 2019 at 01:15:48PM +0100, Dimitri John Ledkov wrote:
> > > > > - lz4 size weight over gzip is marginal (14%) but imho worth the
> > > > > improved boot time & initrd creation time
> > > >
> > > > A 14% increase in initramfs size is NOT marginal. Since there are (and will
> > > > always be) various scenarios which require a separate /boot partition, we
> > > > have over several cycles been contending with how to ensure a clean upgrade
> > > > as kernel+initramfs sizes increase over time and push up against the space
> > > > limits of the boot partitions that have historically been created.
> > > >
> > > > If you are making a change that increases the size of initramfses by 14%
> > > > across the board, you must also:
> > > >
> > > > - update the ubuntu-release-upgrader code to take this into account so
> > > > users don't run out of space in the middle of the upgrade
> > > > - possibly in a way that is smart enough to know if a user is already
> > > > configuring initramfs-tools to use a non-default compressor, to avoid
> > > > false-positives
> > > > - check that the minimum size requirements for /boot that are encoded in
> > > > the installers are still adequate, or if they need updating (and if they
> > > > need updating, update this back to 18.04)
> > > > - document this issue in the release notes
> > >
> >
> > ubuntu-release-upgrader is dynamically calculated, but I have now
> > proposed to bump/update the fallback guestimate.
> >
> > did the calculation of new size requirements, and /boot sizes are
> > still well enough (up to 10 kernels)
> >
> > release notes updated
> >
>
> The Cking recent lz4 measurements tests are documented in the
> description of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840934
> On Tue, 15 Oct 2019 at 11:13, Dimitri John Ledkov <xnox@ubuntu.com> wrote:
> >
> > On Wed, 5 Jun 2019 at 21:25, Dimitri John Ledkov <xnox@ubuntu.com> wrote:
> > >
> > > On Wed, 5 Jun 2019 at 19:59, Steve Langasek <steve.langasek@ubuntu.com> wrote:
> > > >
> > > > Hi Dimitri,
> > > >
> > > > One point here:
> > > >
> > > > On Wed, Jun 05, 2019 at 01:15:48PM +0100, Dimitri John Ledkov wrote:
> > > > > - lz4 size weight over gzip is marginal (14%) but imho worth the
> > > > > improved boot time & initrd creation time
> > > >
> > > > A 14% increase in initramfs size is NOT marginal. Since there are (and will
> > > > always be) various scenarios which require a separate /boot partition, we
> > > > have over several cycles been contending with how to ensure a clean upgrade
> > > > as kernel+initramfs sizes increase over time and push up against the space
> > > > limits of the boot partitions that have historically been created.
> > > >
> > > > If you are making a change that increases the size of initramfses by 14%
> > > > across the board, you must also:
> > > >
> > > > - update the ubuntu-release-upgrader code to take this into account so
> > > > users don't run out of space in the middle of the upgrade
> > > > - possibly in a way that is smart enough to know if a user is already
> > > > configuring initramfs-tools to use a non-default compressor, to avoid
> > > > false-positives
> > > > - check that the minimum size requirements for /boot that are encoded in
> > > > the installers are still adequate, or if they need updating (and if they
> > > > need updating, update this back to 18.04)
> > > > - document this issue in the release notes
> > >
> >
> > ubuntu-release-upgrader is dynamically calculated, but I have now
> > proposed to bump/update the fallback guestimate.
> >
> > did the calculation of new size requirements, and /boot sizes are
> > still well enough (up to 10 kernels)
> >
> > release notes updated
> >
>
> The Cking recent lz4 measurements tests are documented in the
> description of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840934
And also in comment #5 of that same bug.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840934/comments/5
--
Brian Murray
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Supporting LZ4 as initramfs compressor
On Tue, 15 Oct 2019 at 11:13, Dimitri John Ledkov <xnox@ubuntu.com> wrote:
>
> On Wed, 5 Jun 2019 at 21:25, Dimitri John Ledkov <xnox@ubuntu.com> wrote:
> >
> > On Wed, 5 Jun 2019 at 19:59, Steve Langasek <steve.langasek@ubuntu.com> wrote:
> > >
> > > Hi Dimitri,
> > >
> > > One point here:
> > >
> > > On Wed, Jun 05, 2019 at 01:15:48PM +0100, Dimitri John Ledkov wrote:
> > > > - lz4 size weight over gzip is marginal (14%) but imho worth the
> > > > improved boot time & initrd creation time
> > >
> > > A 14% increase in initramfs size is NOT marginal. Since there are (and will
> > > always be) various scenarios which require a separate /boot partition, we
> > > have over several cycles been contending with how to ensure a clean upgrade
> > > as kernel+initramfs sizes increase over time and push up against the space
> > > limits of the boot partitions that have historically been created.
> > >
> > > If you are making a change that increases the size of initramfses by 14%
> > > across the board, you must also:
> > >
> > > - update the ubuntu-release-upgrader code to take this into account so
> > > users don't run out of space in the middle of the upgrade
> > > - possibly in a way that is smart enough to know if a user is already
> > > configuring initramfs-tools to use a non-default compressor, to avoid
> > > false-positives
> > > - check that the minimum size requirements for /boot that are encoded in
> > > the installers are still adequate, or if they need updating (and if they
> > > need updating, update this back to 18.04)
> > > - document this issue in the release notes
> >
>
> ubuntu-release-upgrader is dynamically calculated, but I have now
> proposed to bump/update the fallback guestimate.
>
> did the calculation of new size requirements, and /boot sizes are
> still well enough (up to 10 kernels)
>
> release notes updated
>
>
> On Wed, 5 Jun 2019 at 21:25, Dimitri John Ledkov <xnox@ubuntu.com> wrote:
> >
> > On Wed, 5 Jun 2019 at 19:59, Steve Langasek <steve.langasek@ubuntu.com> wrote:
> > >
> > > Hi Dimitri,
> > >
> > > One point here:
> > >
> > > On Wed, Jun 05, 2019 at 01:15:48PM +0100, Dimitri John Ledkov wrote:
> > > > - lz4 size weight over gzip is marginal (14%) but imho worth the
> > > > improved boot time & initrd creation time
> > >
> > > A 14% increase in initramfs size is NOT marginal. Since there are (and will
> > > always be) various scenarios which require a separate /boot partition, we
> > > have over several cycles been contending with how to ensure a clean upgrade
> > > as kernel+initramfs sizes increase over time and push up against the space
> > > limits of the boot partitions that have historically been created.
> > >
> > > If you are making a change that increases the size of initramfses by 14%
> > > across the board, you must also:
> > >
> > > - update the ubuntu-release-upgrader code to take this into account so
> > > users don't run out of space in the middle of the upgrade
> > > - possibly in a way that is smart enough to know if a user is already
> > > configuring initramfs-tools to use a non-default compressor, to avoid
> > > false-positives
> > > - check that the minimum size requirements for /boot that are encoded in
> > > the installers are still adequate, or if they need updating (and if they
> > > need updating, update this back to 18.04)
> > > - document this issue in the release notes
> >
>
> ubuntu-release-upgrader is dynamically calculated, but I have now
> proposed to bump/update the fallback guestimate.
>
> did the calculation of new size requirements, and /boot sizes are
> still well enough (up to 10 kernels)
>
> release notes updated
>
The Cking recent lz4 measurements tests are documented in the
description of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840934
--
Regards,
Dimitri.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Supporting LZ4 as initramfs compressor
On Wed, 5 Jun 2019 at 21:25, Dimitri John Ledkov <xnox@ubuntu.com> wrote:
>
> On Wed, 5 Jun 2019 at 19:59, Steve Langasek <steve.langasek@ubuntu.com> wrote:
> >
> > Hi Dimitri,
> >
> > One point here:
> >
> > On Wed, Jun 05, 2019 at 01:15:48PM +0100, Dimitri John Ledkov wrote:
> > > - lz4 size weight over gzip is marginal (14%) but imho worth the
> > > improved boot time & initrd creation time
> >
> > A 14% increase in initramfs size is NOT marginal. Since there are (and will
> > always be) various scenarios which require a separate /boot partition, we
> > have over several cycles been contending with how to ensure a clean upgrade
> > as kernel+initramfs sizes increase over time and push up against the space
> > limits of the boot partitions that have historically been created.
> >
> > If you are making a change that increases the size of initramfses by 14%
> > across the board, you must also:
> >
> > - update the ubuntu-release-upgrader code to take this into account so
> > users don't run out of space in the middle of the upgrade
> > - possibly in a way that is smart enough to know if a user is already
> > configuring initramfs-tools to use a non-default compressor, to avoid
> > false-positives
> > - check that the minimum size requirements for /boot that are encoded in
> > the installers are still adequate, or if they need updating (and if they
> > need updating, update this back to 18.04)
> > - document this issue in the release notes
>
>
> On Wed, 5 Jun 2019 at 19:59, Steve Langasek <steve.langasek@ubuntu.com> wrote:
> >
> > Hi Dimitri,
> >
> > One point here:
> >
> > On Wed, Jun 05, 2019 at 01:15:48PM +0100, Dimitri John Ledkov wrote:
> > > - lz4 size weight over gzip is marginal (14%) but imho worth the
> > > improved boot time & initrd creation time
> >
> > A 14% increase in initramfs size is NOT marginal. Since there are (and will
> > always be) various scenarios which require a separate /boot partition, we
> > have over several cycles been contending with how to ensure a clean upgrade
> > as kernel+initramfs sizes increase over time and push up against the space
> > limits of the boot partitions that have historically been created.
> >
> > If you are making a change that increases the size of initramfses by 14%
> > across the board, you must also:
> >
> > - update the ubuntu-release-upgrader code to take this into account so
> > users don't run out of space in the middle of the upgrade
> > - possibly in a way that is smart enough to know if a user is already
> > configuring initramfs-tools to use a non-default compressor, to avoid
> > false-positives
> > - check that the minimum size requirements for /boot that are encoded in
> > the installers are still adequate, or if they need updating (and if they
> > need updating, update this back to 18.04)
> > - document this issue in the release notes
>
ubuntu-release-upgrader is dynamically calculated, but I have now
proposed to bump/update the fallback guestimate.
did the calculation of new size requirements, and /boot sizes are
still well enough (up to 10 kernels)
release notes updated
--
Regards,
Dimitri.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Monday, 14 October 2019
Re: [Launchpad-dev] Reconsidering Ubuntu bug-filing redirection
On Mon, Oct 14, 2019 at 12:13:30PM +0100, Colin Watson wrote:
> I think we should reconsider Launchpad's bug-filing redirection for
> Ubuntu a little bit. While it's serviceable and there are good reasons
> for it to exist, it's also a somewhat frequent source of confusion and
> annoyance, often directed at the Launchpad team.
> I think we should reconsider Launchpad's bug-filing redirection for
> Ubuntu a little bit. While it's serviceable and there are good reasons
> for it to exist, it's also a somewhat frequent source of confusion and
> annoyance, often directed at the Launchpad team.
I agree we should fix this. At the time the change was driven mainly
because we were struggling to keep up with triage, and bug volume is
still a valid concern, but one I'd rather we fixed in other ways (for
instance, better duplicate matching, more demanding triage policy, etc).
The resulting UI is too heavy-handed and we never went back to fix it,
so thanks for raising it.
> Ubuntu gets a lot of incoming bug reports, some percentage of which are
> low-quality.
It's surprising that even with the redirect we still get a volume of
stuff like:
It's also true that these are the easiest "bad" bugs to deal with. The
hardest ones are where there is obviously a real problem but there isn't
enough data to proceed with it, or ones around hardware problems where
the symptoms are confusingly clustered. Removing the redirect may
increase all of these, but it's probably still worth doing.
> * Rearrange the UX for reporting bugs on Ubuntu as a non-member of
> ~ubuntu-bugcontrol so that it presents the reference to ReportingBugs
> and the advice to use ubuntu-bug in a way that's hard to ignore but
> that can still be skipped. For example, much like the way we
> currently have a first step of the bug-filing form that presents
> people with possible duplicates, we could have another step that
> guides people towards using ubuntu-bug; they'd only get the full form
> if they skip that as well.
>
> (I'd suggest that a good test for whether this has been done well is
> if we can tolerate removing the special case for members of
> ~ubuntu-bugcontrol. It isn't a great sign when we have to exempt
> developers from something partly because it's too annoying.)
>
> * Remove the redirection entirely from /ubuntu/+source/PACKAGE/+filebug
> pages (though retaining the bug reporting guidelines displayed
> there), keeping it only on /ubuntu/+filebug. This would still serve
> the purpose of stemming the flow of low-value bug reports that don't
> specify a package name, while making it easier for people who at
> least have some idea which bit of software is going wrong.
Perhaps as a starting point, why not run a one-week experiment where the
redirect is simply removed altogether? That is really easy to do and
would give you data to decide how the changes above would affect Ubuntu.
In terms of approach, I'm +1 on both ideas, though I'm curious if the
latter is going to cause a problem for packages with straightforward
package names, for instance https://launchpad.net/ubuntu/+source/firefox/+bugs
which is easy to get as hit #1 on Google.
--
Christian Robottom Reis | [+55 16] 3376 0125 | http://async.com.br/~kiko
| [+55 16] 991 126 430 | http://launchpad.net/~kiko
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reconsidering Ubuntu bug-filing redirection
I think we should reconsider Launchpad's bug-filing redirection for
Ubuntu a little bit. While it's serviceable and there are good reasons
for it to exist, it's also a somewhat frequent source of confusion and
annoyance, often directed at the Launchpad team.
Ubuntu a little bit. While it's serviceable and there are good reasons
for it to exist, it's also a somewhat frequent source of confusion and
annoyance, often directed at the Launchpad team.
== Background ==
Ubuntu gets a lot of incoming bug reports, some percentage of which are
low-quality. apport was developed partly to try to improve the quality
of incoming bugs by gathering more relevant information about them from
the user's system, either when the bug is filed (using "ubuntu-bug" or
"apport-bug") or after the fact (using "apport-collect").
Furthermore, at one point the bulk of incoming bugs were apparently
filed against Ubuntu directly (without a package name), making life
especially difficult for bug triagers.
About ten years ago [1] [2], Launchpad was changed so that, if people
try to file a bug on Ubuntu directly via the web, then they're instead
redirected to https://help.ubuntu.com/community/ReportingBugs which
explains how to file a bug using the appropriate tools. Some way down,
this explains how to file bugs manually and bypass this redirection.
Members of Ubuntu's bug supervisor team [3], including Ubuntu
developers, are exempted from this redirection; if I remember correctly,
this was on the grounds that we should know what makes an effective bug
report and that it would otherwise be too annoying for us.
At the time, this change was described as an experiment. I think it's
worth having a look at this and seeing if we can tweak it to reduce some
sources of frustration.
[1] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-September/000624.html
[2] https://bugs.launchpad.net/launchpad/+bug/423862
[3] https://launchpad.net/~ubuntu-bugcontrol
== Problem ==
The fact that Ubuntu developers are exempted from this redirection means
that we also don't experience the frustration caused by it. Some
samples I've found over the years:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/521003
https://bugs.launchpad.net/launchpad/+bug/873769
https://bugs.launchpad.net/ubuntu/+bug/1482430
https://bugs.launchpad.net/launchpad/+bug/1629533
https://bugs.launchpad.net/launchpad/+bug/1732438
https://bugs.launchpad.net/launchpad/+bug/1847647 (first part)
Anecdotally, one thing I've noticed is that the people coming to the
Launchpad team on IRC and the like with complaints about this are often
reasonably experienced free software people who just aren't particularly
plugged into Ubuntu's processes. Their bug reports are often valuable,
and not the sort of thing that a hundred other people are going to
report anyway, but they just can't figure out how to file them without
help.
The information about how to file a bug manually is deliberately [4]
buried deep in a wall of text on
https://help.ubuntu.com/community/ReportingBugs. I find it very easy to
see how people could read that multiple times and still miss it (indeed,
over the years I've spoken to several people who have done exactly
that).
I understand what we were trying to do by introducing this redirection,
but I think it goes slightly too far.
[4] https://lists.ubuntu.com/archives/ubuntu-users/2012-August/262951.html
== Suggestions ==
https://wiki.ubuntu.com/QATeam/Specs/IncreaseApportAdoption has various
approaches that were considered. I'd like to say up-front that I don't
think we should do things like expanding the set of people who bypass
the redirection based on karma: this isn't because I object on principle
to making decisions based on Launchpad karma, but because letting more
people bypass the confusing UX is really just papering over the
confusing UX and doesn't solve the underlying problem.
I think we could consider other approaches in the Launchpad UI to give
people a nudge towards good local bug-reporting tools while being
slightly less user-hostile to people who know what they're doing about
bugs in general but not about Ubuntu's processes. I have two specific
independent ideas that I'd like to submit for consideration:
* Rearrange the UX for reporting bugs on Ubuntu as a non-member of
~ubuntu-bugcontrol so that it presents the reference to ReportingBugs
and the advice to use ubuntu-bug in a way that's hard to ignore but
that can still be skipped. For example, much like the way we
currently have a first step of the bug-filing form that presents
people with possible duplicates, we could have another step that
guides people towards using ubuntu-bug; they'd only get the full form
if they skip that as well.
(I'd suggest that a good test for whether this has been done well is
if we can tolerate removing the special case for members of
~ubuntu-bugcontrol. It isn't a great sign when we have to exempt
developers from something partly because it's too annoying.)
* Remove the redirection entirely from /ubuntu/+source/PACKAGE/+filebug
pages (though retaining the bug reporting guidelines displayed
there), keeping it only on /ubuntu/+filebug. This would still serve
the purpose of stemming the flow of low-value bug reports that don't
specify a package name, while making it easier for people who at
least have some idea which bit of software is going wrong.
--
Colin Watson [cjwatson@ubuntu.com]
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Subscribe to:
Posts (Atom)