On Mon, Mar 31, 2014 at 1:37 AM, Jürgen Schmidt <jogischm...@gmail.com>wrote:
> On 3/29/14 5:29 PM, Dave Fisher wrote: > > > > > > Sent from my iPhone > > > >> On Mar 29, 2014, at 6:44 AM, Rob Weir <robw...@apache.org> wrote: > >> > >>> On Sat, Mar 29, 2014 at 7:14 AM, Andrea Pescetti <pesce...@apache.org> > wrote: > >>>> On 27/03/2014 Jürgen Schmidt wrote: > >>>> > >>>>> On 3/27/14 1:59 AM, Andrea Pescetti wrote: > >>>>> > >>>>> Is there interest for a "live" (meaning: IRC + video, like Google > >>>>> Hangouts or similar) meeting to make sure that we (developers, QA, > >>>>> Localization, Documentation, website...) are all on the same page > >>>>> regarding the upcoming 4.1 release? > >>>> > >>>> we can try such a meeting but I don't see the benefit compared to a > >>>> clear communication on the mailing list (can be of course improved). > >>> > >>> > >>> The benefit would be: make sure that active volunteers have a chance > to be > >>> heard and to influence the release. We are doing good now; still, we > can do > >>> better. See below for concrete examples. > >>> > >>> > >>>> Either we do it in a more organized way and define exactly what we > >>>> expect or I am not interested. > >>> > >>> > >>> I am not interested in the other option. Well, maybe I misunderstood > what > >>> you mean by "organized", but for sure I would find it overkill that we > have > >>> to vote for someone to be in a call to represent a certain group (say, > QA) > >>> and vote on what the call topics should be. It's an informal meeting. > >>> > >>>>> It wouldn't be a meeting where things are decided (we have the lists > for > >>>>> that!), but merely a meeting where people can inform each other to > make > >>>>> sure that all priorities are being addressed ... > >>>> > >>>> I am in favor of having such discussion mainly on the list to have it > >>>> documented. > >>> > >>> > >>> Note that it's more about being informed (about stuff that is already > >>> somewhere on the lists), and discussion can follow on lists. > >>> > >>> Maybe it helps if I make a concrete past example: the "Restore windows" > >>> problem https://issues.apache.org/ooo/show_bug.cgi?id=119006 has been > known > >>> for two years. It only triggered on certain versions of Mac OS X and > only > >>> after a crash. Still it caused 500+ e-mails, and probably countless > forum > >>> posts and some enraged/lost users. In retrospect, we should have > evaluated > >>> it better. > >>> > >>> How can we avoid the next "Restore windows", i.e., something that is > known, > >>> important to someone, already documented somewhere but that would > deserve > >>> better attention? It's important for OpenOffice as a project that > active > >>> volunteers feel that they can influence the release. And it is also > very > >>> good for OpenOffice as a product. > >>> > >>> Now, the obvious answer is "Just place it in Bugzilla and nominate it > as a > >>> release blocker". This doesn't always work. For a release blocker, for > >>> example, you would require in most cases that a patch is available, > and a > >>> description that is purely technical can miss to state why it is > important > >>> to get it fixed before release. And if you look at who is nominating > >>> blockers, you'll see that only a few people do that. > >>> > >>> The IRC+video meeting is the best solution I can find, but anything > else > >>> that guarantees proper escalation would work for me. Just, asking > people to > >>> simply follow the process is too demanding on volunteers and we need to > >>> streamline it (another concrete example? we don't have 4.0 in Danish > mainly > >>> due to bad communication, since translation was completed before the > 4.0 > >>> release but after the deadlines). > >>> > >>> If you want yet another example... we already know that OpenOffice 4.1 > is > >>> going to have display problems for Gnome 3 users on Linux. Two bugs > have > >>> clearly been identified: no refresh on fields > >>> https://issues.apache.org/ooo/show_bug.cgi?id=124482 and no scrollbars > >>> https://issues.apache.org/ooo/show_bug.cgi?id=121627 ; the former has > a > >>> working patch by Andre and I'll nominate it as a blocker, but what > about the > >>> latter? Does it make sense to nominate it even if we don't have a fix > >>> available? Will a meeting where active people can report on what they > see on > >>> the forums, lists etc help in making the assessment? > >> > >> We can always have a Hangout on our Google+ page. But I think that is > >> limited to 10 people and ties us to a specific time, making it more or > >> less convenient to people depending on their timezone. So I'm not > >> sure it is much more inclusive. > >> > >> But you could make the argument that it is a best practice with Agile > >> methodology for us to have "daily scrum" meeting to check in and > >> review blockers. But that could also be done via the mailing list, > >> with a new thread each day, e.g., "2014-03-29 Daily Scrum". > > > > As I read the other emails I was thinking that a bug scrub would be > good. This would allow a group to discuss bugs and issues. The goal would > be a priority list which could then be shared on list, debated. We can then > commit ( agile term). Daily scrum then tracks the progress towards the > goal. The scrum master records the info. Scrum master can change from day > to day. It is clerical. > > > > we can stop discussion on such scrum or whatever meetings as long as we > don't have more developers. > > Take a look on the issues that came in over the weekend, 124553 a crash > on Linux when you select a table and some text below or before. I am > really asking if anybody has used the Beta version on Linux and used > form some simple tasks? And taking this issue as example should we > really accept Linux issues as showstopper? > Well...two opinions from me: * yes, Linux issues should be used as showstoppers when appropriate. The issue here is there are a variety of Linux architectures -- 32- and 64-bit, and a variety of graphical environments. A number of us DO test on Linux, but as the old saying goes -- "Your mileage may vary." * I'm much prefer mailing lists for ANY planning and discussion. If needed, "proposed showstoppers" can be discussed at length. > Ok don't take me to serious but I hope you see my point. We have a > problem but that can't be solved with such meetings. > > @andrea, my point is that I am not interested in an informal meeting > without a special outcome. Issues of broader interest get attention if > they are communicated on the list and we have no timezone issues. > > But we don't need a Beta in the future if such issues as above are not > found over month. > > Nevertheless will be a new snapshot available later today (hopefully if > the upload of the windows builds is fast enough). > > Juergen > > > > > Regards, > > Dave > > > >> > >> In any case, if a PMC member wants to take the lead on a hangout, and > >> does not already have access to our Google+ page, let me know and I > >> can give you manager access. > >> > >> -Rob > >> > >> > >>> Regards, > >>> Andrea. > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >>> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > -- ------------------------------------------------------------------------------------------------- MzK "Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect." -- James Mason
