+1 Thanks, Eduard
On Thu, Dec 31, 2015 at 10:00 AM, Thomas Mortagne <[email protected] > wrote: > ok to continue what we were doing > > On Wed, Dec 30, 2015 at 5:16 PM, [email protected] <[email protected]> > wrote: > > I see there’s been no reply to this last email. > > > > Are we all ok for this last proposal? > > > > Thanks > > -Vincent > > > > > > On 16 Nov 2015 at 08:43:30, [email protected] ([email protected] > (mailto:[email protected])) wrote: > > > >> Ok. I propose that we simply agree on this best practice for now and we > try it without any automation and see how it goes: > >> > >> > >> Proposal text to add to our best practices on xwiki.org: > >> > >> " > >> When someone reports or notices a blocker issue that will affect end > users in a serious way (the definition of “serious” is left to the > discretion of everyone), he should add it in the error block at the top of > the release notes in which the issue exists. > >> > >> The error block should have the following format: > >> > >> {{error}} > >> The following important issues were found after this version was > released. You should verify if you’re using or need the affected features > and decide whether to use a newer version that has it fixed or continue > with this release: > >> > >> * > >> * … > >> * > >> {{/error}} > >> " > >> > >> > >> Thanks > >> -Vincent > >> > >> > >> On 16 Nov 2015 at 02:08:00, Denis Gervalle ([email protected]) wrote: > >> > >> On Sun, Nov 15, 2015 at 1:02 PM, [email protected] > >> wrote: > >> > >> > Hi Denis, > >> > > >> > Thanks for your feedback, see below. > >> > > >> > On 15 Nov 2015 at 12:30:13, Denis Gervalle ([email protected](mailto: > >> > [email protected])) wrote: > >> > > >> > > On Fri, Nov 13, 2015 at 9:48 PM, [email protected] > >> > > wrote: > >> > > > >> > > > > >> > > > > >> > > > On 13 Nov 2015 at 19:35:56, Eduard Moraru ([email protected] > >> > (mailto: > >> > > > [email protected])) 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 > >> > > > >> > > > >> > > 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. > >> > > > >> > > > >> > > > 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. > >> > > >> > This is what I was trying to say with “for me a blocker is a > blocker”. I think > >> > we’re saying the same thing here: > >> > * We need a way to mark (in JIRA) very important issues that affect > some > >> > user-feature of xwiki (since RN are for users) > >> > * I agree that regressions don’t have to be blockers (and they’re not > all, > >> > there are several regressions we don’t mark as blockers because > they’re > >> > not…). You should know since the Mail API has had a few regressions > you > >> > introduced and they’re marked as regressions but not blockers ;) > >> > > >> > > 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 > >> > ? > >> > > >> > Yes that’s the risk and that’s the reason we have created manual > release > >> > notes indeed. Because just listing jira issues is not user-friendly > enough. > >> > > >> > > And on the other side, XWIKI-12218, while we want it in the next > release, > >> > > was it really so blocker for end users ? > >> > > >> > Again, there’s only a global process which is to separate real > blockers > >> > from a user POV (which we want highlighted in the RN) from important > issues > >> > that we want fixed but that are not really blockers for users. > >> > > >> > The only question is when do we do this separation: > >> > > >> > * Proposal 1 (Vincent): Do this sorting in JIRA and have a generic > query > >> > in the RN for listing those issues > >> > > >> * Proposal 2 (Denis, Edy): This is what we do now. Continue doing this > >> > sorting at random, by random people when they think about it. In most > cases > >> > it’s forgotten and not added to RN. > >> > > >> > >> I do not know for Edy, but for the above definition does not really > >> translate what I have said so far ! > >> What I said, is that we cannot simply list blockers at the top to > replace > >> the actual manual warnings because JIRA tickets are often unintelligible > >> for end users, and that all blockers (as we used to do them so far) are > not > >> at the same level, and does not necessarily need to be enhanced at the > same > >> level. That if we go that way, it means we need to rethink the way we > use > >> blocker in JIRA, and that I do not believe we should. > >> > >> > >> > > >> > I’m in favor of proposal 1, ie improve our JIRA tagging so that we > >> > identify real user blockers and list them automatically in the RN. > This > >> > would be the same process as we have now, ie we review issues being > created > >> > every day > >> > > >> > I’d be also ok for proposal 2 but only if we can define a process so > that > >> > we don’t forget about them (and that it’s not me doing it most of the > time > >> > and being the bad guy reminding everyone). > >> > > >> > > 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. > >> > > >> > I think listing in red at the top is ok for really serious issues (ie > real > >> > blockers from user POV), i.e. to tell users to NOT use this version > if they > >> > used the feature mentioned. > >> > > >> > >> If this is really intelligible from the simple JIRA title, I would be > +1, > >> but I doubt we can really achieve that. > >> > >> > >> > > >> > > 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. > >> > > >> > That would be fine IMO because it would mean they’re not real > blockers and > >> > that releasing without them is ok. In the end what should be blocking > us > >> > from a release is the real end user blockers. > >> > > >> > >> Again, I am not sure this is so simple. Marking issue as blocker is > >> promising issues to be fixed for the release, and if this does not > really > >> happen, be sure we care a lot about them, and not simply push them to > the > >> next release without an agreement. This does not necessarily means that > the > >> issue affect a large amount of users, and that it is so important that > it > >> should prevent many users to try that release. > >> > >> > >> > > 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 ? > >> > > >> > Yep I think this is the real question. > >> > > >> > > 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. > >> > > >> > I’m ok to not change our current usage of blockers but I don’t > understand > >> > what you’re suggesting for RN. You’re not addressing the reason for > this > >> > thread in the first place, which is that I feel that we just add > warning at > >> > random and we forget a lot and that it’s mostly me doing it. How do we > >> > prevent what happened Friday (ie. Marius not adding the blocker to > the top > >> > of the 7.3 RN)? > >> > > >> > >> As I have explained earlier, if we do not change our current usage of > >> blocker (and I like this idea), and if I look at your auto-generated > list > >> of blockers, many of them are unintelligible for the end users, and I do > >> not see what would be the benefit to list them, all it will do, is make > >> users confused or scared. > >> So, the manual decision is difficult to avoid. Maybe we could use a > manual > >> tag to exclude (or include) some blocker from the list, meaning that we > >> would go for a show them by default (or explicitly), and we have a way > to > >> explicitly make them not listed (or listed) while we still consider them > >> for the next release. But, I am not sure this is fine, since anyone (not > >> just committers) could create a blocker JIRA, and cause a change of the > RN… > >> is this acceptable to list unconfirmed blockers ? > >> > >> I do not know exactly what happened on Friday, but I would say that like > >> any manual process, we cannot be fully error safe, but I am sure all of > us > >> will do their best to ensure we care about this in the future. Don’t you > >> trust we could do that ? > >> > >> > >> > > >> > Thanks > >> > -Vincent > >> > > >> > > Thanks, > >> > > > >> > > > >> > > > > >> > > > 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, [email protected] > >> > > > > wrote: > >> > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > On 13 Nov 2015 at 19:14:11, Eduard Moraru ( > [email protected] > >> > > > (mailto: > >> > > > > > [email protected])) 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, [email protected] > >> > > > > > > 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, [email protected] ( > >> > [email protected] > >> > > > ) > >> > > > > > 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]]). > >> > 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, [email protected] ( > >> > [email protected] > >> > > > ) > >> > > > > > 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 > >> > > >> > >> > >> > >> -- > >> Denis Gervalle > >> SOFTEC sa - CEO > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
