Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


Bjoern Michaelsen píše v Út 19. 06. 2012 v 18:40 +0200:
Hi Petr,

On Tue, Jun 19, 2012 at 06:14:18PM +0200, Petr Mladek wrote:
Ah, this bug is about a daily digest. I think that we first need to
decide how much we want to modify the current work flow. Do we want to
really move most discussions from the mailing list to gerrit?

IMHO yes, they are noise on the mailing list as you need deep context to follow
them. In gerrit you can even comment inline in the patch.

Sounds good but how many people would know about the comments? How hard
would be to find them?

How people will be noticed about news in gerrit?

Reporters and Reviewer will get mails about "their" patches. Unless they prefer
a different workflow in which case they can change their preferences. A lot
better than what we have now.

Sure but who will be the reviewer? The mailing list has the advantage
that people step in when they are interested. It helps to balance the
workload. Also it is very open for new reviewers. I am afraid that
gerrit could make some people fell like reviewing robots.

Is one day digest really enough?

For the mailing list, yes. But I might make sense to teach one of our IRC bots
to blurp out updates in realtime to #libreoffice-dev.
One might consider it useful to send _one_ mail to the list once the patch goes
in with a summary of the history, but I personally guess the majority is not
interested in reading that and the few that are can look it up in gerrits web
interface.

Let's discuss this on the ESC meeting. I am afraid that people will not
look into gerrit regularly. For example, I open bugzilla only when I get
a mail about a change or when I see an interesting bug number in mail
conference or irc.

People have only limited time to monitor mailing lists, irc, other
tools. We need to be careful about adding too many channels to monitor.


Well, we should still try to get people on the mailing list (and it will be
easier with less traffic there). Asking a first-time contributor to subscribe
(and send his license blurp) is a good thing. A lot of volunteers told me
though they unsubscribed because of the volume of mails on the dev list. And
the PATCH mails arent exactly those that are socially attractive.

It sounds reasonable. The question is if people will still monitor the
mailing list if there are not interesting patches. Well, I do not want
to be too negative. We need to try it. On the other hand, we need to be
ready to solve these problems ;-)

    + setup mail notifications to the developer mailing list

Yes, and Robert is on that bug (ETA: next week). Otherwise, I will jump in.

Sounds good


    + setup patch drop mailbox
yes, on my todo and halfway there:
 https://launchpad.net/~r-gerrit-0 (bot-id)
 gerrit@libreoffice.org (bot email)

Design proposals on the email format etc. welcome.

I am sure that people will have many good ideas once they see how it is
supposed to work.


    + scripting to automagically identify patches on the mailing
          list

IMHO, we should drop that in favor of explicit forward to
gerrit@libreoffice.org. "Guessing" the target branch is tricky, and a simple
forward (with possibly tweaking the subject to something botreadable) shouldnt
be too hard. 

If the gerrit commandline interface is easy, anyone would be able to
push it for review quickly. We need easy interface anyway.


For inspiration, I attach mail from the openSUSE Build Service. It
includes:

    + description of changes
    + diff of the spec file
    + commands how to get full diff, approve or reject the change

I still think we should reduce the traffic on the dev ml, but having that as
IRC bot would be nice. Such mails are kinda nice for full-time employees, but
for everyone else they are overkill IMHO.

We must not increase the traffic. If active reviewers want notification,
we need to provide it. Let's discuss this on ESC.


Best Regards,
Petr


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.