13 Nov
2015
13 Nov
'15
9:48 p.m.
On 13 Nov 2015 at 19:35:56, Eduard Moraru
(enygma2002@gmail.com(mailto:enygma2002@gmail.com)) wrote:
I am +1 to keep doing what we have been doing so far,
which is, on a
case-by-case basis and depending on the importance of the blocker, to
manually add a notice (/error macro) in the release notes, informing users.
If we want to document this as a best practice, I`m ok with it.
I`m not a fan of increasing maintainance/work load in this aspect, but
that`s just my opinion.
I agree that low maintenance when possible is always better. That was the point of the
automated approach BTW. Even though automated has limitation don’t you think it’s better
than what we’re doing ATM (i.e. adding stuff when we think about it, i.e. missing 80% of
what we should do)?
About this, I don’t agree that what we’ve been doing is good because we almost never do
it. AFAIR I’ve been almost the only one doing it (I could be wrong please correct me if
that’s the case) and pushing others to do it and I would prefer not to have to continue
doing this all the time. An example was later today, we created a very important blocker
and fixed it and yet we didn’t add it to the RN of 7.3 until I raised it and added it
myself. I’d rather not be the one having to think about this and pestering others about
it...
I’d like a common agreement on whether we want to add blockers to RN or not. If we think
it’s not a good idea then I’m fine and we shouldn't add them.
What I’m not fine about is saying that we think we should add blockers and then not to do
it, that doesn’t make sense.
Regarding importance of blockers, for me a blocker is a blocker, otherwise it’s not named
correctly and we should fix this :)
Thanks for your feedback Edy. I’m curious to know what the others think at this point! :)
Thanks
-Vincent
Thanks,
Eduard
On Fri, Nov 13, 2015 at 8:21 PM, vincent(a)massol.net
wrote:
>
>
>
>
>
> On 13 Nov 2015 at 19:14:11, Eduard Moraru (enygma2002(a)gmail.com(mailto:
> enygma2002(a)gmail.com)) wrote:
>
> > Hi,
> >
> > Another problem with automatic is that we don`t always tag
> affects-version
> > on the actual version when it was introduced, but the version we actually
> > tested with. This might lead to displaying blockers on the release notes
> of
> > versions that were not responsible with introducing the actual problem.
> >
> > Until now, we haven`t had that many cases and the 7.2, 7.3 releases could
> > be considered (from my POV) exceptions which had multiple issues due to
> the
> > nature/complexity of the changes they introduced.
> >
> > So, in the end, I believe I`m +1 to stick to manual.
>
> Whether manual or automatic, are you +1 that we do this as a best practice
> (ie always add blockers to RN, at the top and using an error macro)?
>
> Thanks
> -Vincent
>
> >
> > Thanks,
> > Eduard
> >
> > On Fri, Nov 13, 2015 at 7:00 PM, vincent(a)massol.net
> > wrote:
> >
> > > To summarize:
> > >
> > > Pros and cons of automatic:
> > > + Not missing any
> > > - Technical descriptions
> > >
> > > Pros and cons of manual:
> > > + Nice hand-made messages
> > > - Usually missing some, unless we add a process (like have the RM
> ensure
> > > that none are missing the previous release notes)
> > >
> > > WDYT?
> > >
> > > Thanks
> > > -Vincent
> > > On 13 Nov 2015 at 17:56:00, vincent(a)massol.net (vincent(a)massol.net)
> wrote:
> > >
> > > OTOH if we do it automatically we won’t have as nice description as
> what
> > > we can have when we hand-make them. For example on
> > > http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki71
> we
> > > have:
> > >
> > > “
> > > This release introduces a bug concerning the upgrade of the subwikis
> > > ([[XWIKI-12208>>http://jira.xwiki.org/browse/XWIKI-12208]])208]]). You
can
> > > still upgrade them via Distribution Wizard but only at the same time
> you
> > > upgrade the main wiki. You can also upgrade your subwiki's UI like
any
> > > other extensions, by clicking on "Check for updates".
> > >
> > > The best is to wait for the release of 7.1.1 which will fix this
> problem
> > > and should be ready really soon.
> > > "
> > >
> > > And if we use the strategy below we get:
> > > https://www.evernote.com/l/AHfEQXsj4mNH4pjXgxuiL4uZiomR5kUpkpA
> > >
> > > As you can see on the screenshot if we do it manually we’re missing a
> lot
> > > of blocker issues.
> > >
> > > WDYT?
> > >
> > > Thanks
> > > -Vincent
> > >
> > >
> > > On 13 Nov 2015 at 17:51:50, vincent(a)massol.net (vincent(a)massol.net)
> wrote:
> > >
> > > Hi devs,
> > >
> > > I’d like to suggest a new best practice which would consist in
> > > systematically adding blockers issues in the release notes
> corresponding to
> > > the affects versions, at the top, using an error macro. For example
> I’ve
> > > updated the release notes for 7.2 and 7.3:
> > > - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki72
> > > - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki73
> > >
> > > The idea would be to update our Release Notes template to automatically
> > > list them using this template snippet (example for XWiki 7.2):
> > >
> > > "
> > > {{error}}
> > > The following blocking issues were found after this version was
> released.
> > > You should verify if you're using the affected features and if so,
you
> can
> > > click on them to see in which version they are fixed):
> > >
> > > {{jira url="http://jira.xwiki.org" style="list"
source="jql"}}
> > > category = "Top Level Projects" and affectedVersion in
> > > ("7.2-milestone-1", "7.2-milestone-2",
"7.2-milestone-3", "7.2-rc-1",
> > > "7.2") and fixVersion > "7.2" and priority =
Blocker and resolution =
> Fixed
> > > {{/jira}}
> > > {{/error}}
> > > “
> > >
> > > The goal is to make it easy for our end users to see blocking issues
> in a
> > > given release. The goal is also to make it visible to us how many
> blockers
> > > we introduce in each release and work on reducing this number as much
> as
> > > possible.
> > >
> > > WDYT?
> > >
> > > Thanks
> > > -Vincent