15 Nov
2015
15 Nov
'15
12:29 p.m.
On Fri, Nov 13, 2015 at 9:48 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 13 Nov 2015 at 19:35:56, Eduard Moraru (enygma2002(a)gmail.com(mailto:
enygma2002(a)gmail.com)) wrote:
I can only speak for myself, but I do as well. Now it depends of the nature
of the blocker. All regression are blockers, but the regression could still
be minor and not so annoying for most users. In that case, I do not. Up to
now, what we put at the top in error box were blocker that we think make
the release unrecommended for most users. And IMO, we should continue doing
this manually at least.
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.
We already add know issue we know about to the RN, so adding blockers at
the top is not really adding them to the RN, but making them more visible.
This could be a good idea but not in replacement to our current practice,
since it is less understandable, and more common then our current practice,
making the information less meaningful for users. This could even cause
more confusion, if those blocker are minor regression on specific areas.
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 :)
This is not so true, blocker means we don’t want this in the next release,
and as I said, it is generally true for any regression. But the actual
blocker could have several level of importance for different kind of user,
and in the end only affect very few of them but so hardly that it is still
blocker. If you look at your sample, I am even afraid by what users will
understand of them. Either they will be afraid so much, that they will not
upgrade, or they will not understand and consider they are not affected.
See XWIKI-12502, XWIKI-12342, XWIKI-12251, what users will think of them ?
And on the other side, XWIKI-12218, while we want it in the next release,
was it really so blocker for end users ? In your example above, those that
could be interesting and understandable warnings for some users are
XWIKI-12612, XWIKI-12160 and XWIKI-11993.
So listing them in red at the very top may be too much, or confusing IMO.
This does not mean the the could not list them somewhere in the RN, maybe
in a {{warning}} macro, below the possible {{error}} we do manually. This
could also help us think about doing a red one, when looking at the RN.
What afraid me in the end, is that we do less blockers just because we know
they will appear in RN and they are so technical that nobody will get it.
So the next question is, does all of them represent what you wanted at the
top, compare to other issues ? Is those blocker more significant ? Should
we change the way we use blocker ?
I am not sure we should change anything in our current usage of blocker, we
may want to have them enhanced in RN, but it does not mean all the
information will be so significant.
Thanks,
Thanks for your feedback Edy. I’m curious to know what the others think at
this point! :)
Thanks
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs