Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?

Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?

[Fabio Fantoni]

I saw some discussions about the developer cycle, patch review and how 
to improve.

Based on what I saw an important thing for improve efficiency and 
spending less time is the way of communication, actual seems only 
mailing-list/mails.

It seems to me that currently has some limits and in many cases takes a 
long time for some specific searches,trouble finding patches that need 
attention etc...

A good solution I think would be a forum specific for developing with 
these features:
- light even if with many specific features useful for developing and 
compatible with all browser and devices
- have all as forum discussion that is easier to search, access to all 
post etc... now the search is only via web for month (losing link in 
different months) and with mail (if storing thousands of emails per month)
- possibility to include group or single users (for example maintainers) 
to a discussion (also notify with mails based on specific destination 
users settings), better that send mails, faster for search, will avoid 
also problem of mails not received, mail address changed etc...
- good patch "integration", possibility to include/see/download patches, 
raw vision (like the patch sent now with mail with git), add of special 
tags etc... This is probably the more difficult thing to do because need 
to find the best way to manage well the patches, including series and 
ultimately have a better solution to track, review, comment, etc...
- optionally automatic include maintainer for patch posted, probably 
after loading it on server scanning with a similar to 
scripts/get_maintainer.pl
- advanced searching including if is a normal discussion or patch, if 
the user is present on notify list, selection of all tags, for example 
for search in patch that are fix or features, is the discussion/patch is 
without reply or with reply older that specified range (faster search of 
patch without review, or without recent reply), is closed (about patch 
if merged) or not


I did a fast internet search about without find a similar solution, the 
only near thing is probably forum with some specific extension (if exist).
There are some solutions with part of these goals but lacking in some 
important, for example github.

What do you think about this?


Thanks for any reply and sorry for my bad english.

Re: Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?

[Wei Liu]

CC Lars.

On Mon, Aug 31, 2015 at 03:46:30PM +0200, Fabio Fantoni wrote:
> I saw some discussions about the developer cycle, patch review and how to
> improve.
> 
> Based on what I saw an important thing for improve efficiency and spending
> less time is the way of communication, actual seems only mailing-list/mails.
> 
> It seems to me that currently has some limits and in many cases takes a long
> time for some specific searches,trouble finding patches that need attention
> etc...
> 
> A good solution I think would be a forum specific for developing with these
> features:
> - light even if with many specific features useful for developing and
> compatible with all browser and devices
> - have all as forum discussion that is easier to search, access to all post
> etc... now the search is only via web for month (losing link in different
> months) and with mail (if storing thousands of emails per month)
> - possibility to include group or single users (for example maintainers) to
> a discussion (also notify with mails based on specific destination users
> settings), better that send mails, faster for search, will avoid also
> problem of mails not received, mail address changed etc...
> - good patch "integration", possibility to include/see/download patches, raw
> vision (like the patch sent now with mail with git), add of special tags
> etc... This is probably the more difficult thing to do because need to find
> the best way to manage well the patches, including series and ultimately
> have a better solution to track, review, comment, etc...
> - optionally automatic include maintainer for patch posted, probably after
> loading it on server scanning with a similar to scripts/get_maintainer.pl
> - advanced searching including if is a normal discussion or patch, if the
> user is present on notify list, selection of all tags, for example for
> search in patch that are fix or features, is the discussion/patch is without
> reply or with reply older that specified range (faster search of patch
> without review, or without recent reply), is closed (about patch if merged)
> or not
> 
> 
> I did a fast internet search about without find a similar solution, the only
> near thing is probably forum with some specific extension (if exist).
> There are some solutions with part of these goals but lacking in some
> important, for example github.
> 
> What do you think about this?
> 
> 
> Thanks for any reply and sorry for my bad english.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?

[Lars Kurth]

Adding Russell,


On 31/08/2015 15:16, "Wei Liu" <wei.liu2@citrix.com> wrote:

>CC Lars.
>
>On Mon, Aug 31, 2015 at 03:46:30PM +0200, Fabio Fantoni wrote:
>> I saw some discussions about the developer cycle, patch review and how
>>to
>> improve.
>> 
>> Based on what I saw an important thing for improve efficiency and
>>spending
>> less time is the way of communication, actual seems only
>>mailing-list/mails.
>> 
>> It seems to me that currently has some limits and in many cases takes a
>>long
>> time for some specific searches,trouble finding patches that need
>>attention
>> etc...
>> 
>> A good solution I think would be a forum specific for developing with
>>these
>> features:

Fabio, of course the downside is that some developers are quite happy with
mailing lists. There is also a generational gap: developers that grew up
with lists prefer lists, developers that grew up with forums prefer forums
(the same is true for people starting in FOSS with github, which exposes
forum like functionality). This is a well known problem in many FOSS
communities. 
http://programmers.stackexchange.com/questions/71148/why-do-programmers-sti
ll-use-mailing-lists is covering many topics of that debate (without
getting religious about it).

We did also have a discussion at the 2014 developer meeting, where we
discussed the high volume of traffic on xen-devel. At the time we decided
not to split the list and use better tagging (arm, x86, tools, ...).

Russell has evaluated some off-the shelf tooling that would allow bridging
the gap: unfortunately there is nothing good out there, which works well
in practice. Google groups, which was designed with list support in it
also kind of sucks. However, I believe we still have a project with a
contractor ongoing to try and bridge xen-users with
http://xenproject.org/help/questions-and-answers.html (such that they
become mirrors of each other) - I will let Russell give an update. If that
project gets to the point that the bridge works, that nobody is badly
impacted, maybe we can consider extending it to other lists.



>> - light even if with many specific features useful for developing and
>> compatible with all browser and devices
>> - have all as forum discussion that is easier to search, access to all
>>post
>> etc... now the search is only via web for month (losing link in
>>different
>> months) and with mail (if storing thousands of emails per month)

Actually, this is why provide http://xen.markmail.org/ - it also provides
some advanced search queries (see
http://markmail.org/docs/faq.xqy#searchsyntax)
I can check whether we can configure mhonarc our archiver differently, or
whether there are other options. Maybe there are better archivers we could
look at also

>> - possibility to include group or single users (for example
>>maintainers) to
>> a discussion (also notify with mails based on specific destination users
>> settings), better that send mails, faster for search, will avoid also
>> problem of mails not received, mail address changed etc...

I guess that would be hard to implement (even scripts/get_maintainer.pl
has issues). Also of course the drawback is that the entire contribution
workflow may have to change (it is currently build around git send-email)

>> - good patch "integration", possibility to include/see/download
>>patches, raw
>> vision (like the patch sent now with mail with git), add of special tags
>> etc... This is probably the more difficult thing to do because need to
>>find
>> the best way to manage well the patches, including series and ultimately
>> have a better solution to track, review, comment, etc...

I am not sure, whether there is any decent git integration with any
forums. 

>> - optionally automatic include maintainer for patch posted, probably
>>after
>> loading it on server scanning with a similar to
>>scripts/get_maintainer.pl

See above

>> - advanced searching including if is a normal discussion or patch, if
>>the
>> user is present on notify list, selection of all tags, for example for
>> search in patch that are fix or features, is the discussion/patch is
>>without
>> reply or with reply older that specified range (faster search of patch
>> without review, or without recent reply), is closed (about patch if
>>merged)
>> or not

We may be able to do some of this: I am currently working with a company
called Bitergia which does open source dashboards and analysis of open
source communities. One of these activities is to model the review process
for us, such that we can reliable stats.

You can do some of what you need with the xen mark mail search with
queries such as 'list:xen-devel subject:patch -subject:"Re:"'

There is a problem with identifying stale reviews on mailing lists. Which
is what I assume you are looking for. You can't tell reliably from the
list whether
* a review has ended because the code went into git
* whether it has been abandoned
* whether it is waiting to be looked at

Bitergia have been working on a new UI for other projects. A prototype for
us it at http://projects.bitergia.com/previews/ng/dashboard.html?db=xen :
the data sources are not quite right, the config is not quite right and it
does not cover reviews. In any case, you can filter commits by time, repo,
company, ... The link back to git is currently also not yet working.

A similar view would be available for code reviews: right now, that only
works for projects that use Gerrit or similar tools. But assuming we can
model the review workflow for us, it may be possible to create some custom
searches on that combined database. You can filter by

>> 
>> 
>> I did a fast internet search about without find a similar solution, the
>>only
>> near thing is probably forum with some specific extension (if exist).

I don't think there is much today, which is surprising.

>> There are some solutions with part of these goals but lacking in some
>> important, for example github.

>> 
>> What do you think about this?
>> 
>> 
>> Thanks for any reply and sorry for my bad english.

Your English was great!

>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

Re: Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?

[Russell Pavlicek]

Please forgive the top-post.  I am stuck with an interface which does not facilitate inline replies (as insane as that may sound).

>Russell has evaluated some off-the shelf tooling that would allow bridging
>the gap: unfortunately there is nothing good out there, which works well
>in practice. Google groups, which was designed with list support in it
>also kind of sucks. However, I believe we still have a project with a
>contractor ongoing to try and bridge xen-users with
>http://xenproject.org/help/questions-and-answers.html (such that they
>become mirrors of each other) - I will let Russell give an update. If that
>project gets to the point that the bridge works, that nobody is badly
>impacted, maybe we can consider extending it to other lists.

Lars is correct that the choices are sparse and poor when it comes to skinning existing email lists as forums.  We have a stalled, but on-going, project to skin the xen-users mailing list on the Q&A forum on XenProject.org.  Most of the basic functionality exists in the extension we are trying to use, but functions (emailing certain parties who are interacting via the website) do not work as advertised.  The contractor was following up with the extension provider, but atop-to-bottom reorganization of the contracting company has put the effort on hold for the past several weeks until they reboot their services division (supposedly, "next month"; we'll see).

We were approached by a startup last year which had promising forum-skinning technology, but they were both closed source and expensive.  I think that company may have failed already.

There are a handful of options of integrated forum & mailing list (Discourse being one of the most prominent), but they require recreating the mailing list under the auspices of the tool. So the xen-devel mailing list as we know it would have to be abandoned and/or migrated to the new tool.  That represents a potentially large disturbance to existing users, which isn't desirable.

I haven't reassessed the solution landscape in a few months, so maybe it is time to check again.  But I am not hopeful that we will find a good result.

BTW, if you know someone looking for their next FOSS project, feel free to suggest transparent skinning of an email list with a forum interface.  It is a real niche with no good players.

Russ Pavlicek
Xen Project Evangelist, Citrix Systems
Home Office: +1-301-829-5327
Mobile: +1-301-814-1143
UK VoIP: +44 1223 852 894

________________________________________
From: Lars Kurth
Sent: Monday, August 31, 2015 1:32 PM
To: Wei Liu; Fabio Fantoni; Russell Pavlicek
Cc: xen devel
Subject: Re: [Xen-devel] Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?

Adding Russell,


On 31/08/2015 15:16, "Wei Liu" <wei.liu2@citrix.com> wrote:

>CC Lars.
>
>On Mon, Aug 31, 2015 at 03:46:30PM +0200, Fabio Fantoni wrote:
>> I saw some discussions about the developer cycle, patch review and how
>>to
>> improve.
>>
>> Based on what I saw an important thing for improve efficiency and
>>spending
>> less time is the way of communication, actual seems only
>>mailing-list/mails.
>>
>> It seems to me that currently has some limits and in many cases takes a
>>long
>> time for some specific searches,trouble finding patches that need
>>attention
>> etc...
>>
>> A good solution I think would be a forum specific for developing with
>>these
>> features:

Fabio, of course the downside is that some developers are quite happy with
mailing lists. There is also a generational gap: developers that grew up
with lists prefer lists, developers that grew up with forums prefer forums
(the same is true for people starting in FOSS with github, which exposes
forum like functionality). This is a well known problem in many FOSS
communities.
http://programmers.stackexchange.com/questions/71148/why-do-programmers-sti
ll-use-mailing-lists is covering many topics of that debate (without
getting religious about it).

We did also have a discussion at the 2014 developer meeting, where we
discussed the high volume of traffic on xen-devel. At the time we decided
not to split the list and use better tagging (arm, x86, tools, ...).

Russell has evaluated some off-the shelf tooling that would allow bridging
the gap: unfortunately there is nothing good out there, which works well
in practice. Google groups, which was designed with list support in it
also kind of sucks. However, I believe we still have a project with a
contractor ongoing to try and bridge xen-users with
http://xenproject.org/help/questions-and-answers.html (such that they
become mirrors of each other) - I will let Russell give an update. If that
project gets to the point that the bridge works, that nobody is badly
impacted, maybe we can consider extending it to other lists.



>> - light even if with many specific features useful for developing and
>> compatible with all browser and devices
>> - have all as forum discussion that is easier to search, access to all
>>post
>> etc... now the search is only via web for month (losing link in
>>different
>> months) and with mail (if storing thousands of emails per month)

Actually, this is why provide http://xen.markmail.org/ - it also provides
some advanced search queries (see
http://markmail.org/docs/faq.xqy#searchsyntax)
I can check whether we can configure mhonarc our archiver differently, or
whether there are other options. Maybe there are better archivers we could
look at also

>> - possibility to include group or single users (for example
>>maintainers) to
>> a discussion (also notify with mails based on specific destination users
>> settings), better that send mails, faster for search, will avoid also
>> problem of mails not received, mail address changed etc...

I guess that would be hard to implement (even scripts/get_maintainer.pl
has issues). Also of course the drawback is that the entire contribution
workflow may have to change (it is currently build around git send-email)

>> - good patch "integration", possibility to include/see/download
>>patches, raw
>> vision (like the patch sent now with mail with git), add of special tags
>> etc... This is probably the more difficult thing to do because need to
>>find
>> the best way to manage well the patches, including series and ultimately
>> have a better solution to track, review, comment, etc...

I am not sure, whether there is any decent git integration with any
forums.

>> - optionally automatic include maintainer for patch posted, probably
>>after
>> loading it on server scanning with a similar to
>>scripts/get_maintainer.pl

See above

>> - advanced searching including if is a normal discussion or patch, if
>>the
>> user is present on notify list, selection of all tags, for example for
>> search in patch that are fix or features, is the discussion/patch is
>>without
>> reply or with reply older that specified range (faster search of patch
>> without review, or without recent reply), is closed (about patch if
>>merged)
>> or not

We may be able to do some of this: I am currently working with a company
called Bitergia which does open source dashboards and analysis of open
source communities. One of these activities is to model the review process
for us, such that we can reliable stats.

You can do some of what you need with the xen mark mail search with
queries such as 'list:xen-devel subject:patch -subject:"Re:"'

There is a problem with identifying stale reviews on mailing lists. Which
is what I assume you are looking for. You can't tell reliably from the
list whether
* a review has ended because the code went into git
* whether it has been abandoned
* whether it is waiting to be looked at

Bitergia have been working on a new UI for other projects. A prototype for
us it at http://projects.bitergia.com/previews/ng/dashboard.html?db=xen :
the data sources are not quite right, the config is not quite right and it
does not cover reviews. In any case, you can filter commits by time, repo,
company, ... The link back to git is currently also not yet working.

A similar view would be available for code reviews: right now, that only
works for projects that use Gerrit or similar tools. But assuming we can
model the review workflow for us, it may be possible to create some custom
searches on that combined database. You can filter by

>>
>>
>> I did a fast internet search about without find a similar solution, the
>>only
>> near thing is probably forum with some specific extension (if exist).

I don't think there is much today, which is surprising.

>> There are some solutions with part of these goals but lacking in some
>> important, for example github.

>>
>> What do you think about this?
>>
>>
>> Thanks for any reply and sorry for my bad english.

Your English was great!

>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

Re: Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?

[Fabio Fantoni]

Il 31/08/2015 21:38, Russell Pavlicek ha scritto:
> Please forgive the top-post.  I am stuck with an interface which does not facilitate inline replies (as insane as that may sound).
>
>> Russell has evaluated some off-the shelf tooling that would allow bridging
>> the gap: unfortunately there is nothing good out there, which works well
>> in practice. Google groups, which was designed with list support in it
>> also kind of sucks. However, I believe we still have a project with a
>> contractor ongoing to try and bridge xen-users with
>> http://xenproject.org/help/questions-and-answers.html (such that they
>> become mirrors of each other) - I will let Russell give an update. If that
>> project gets to the point that the bridge works, that nobody is badly
>> impacted, maybe we can consider extending it to other lists.
> Lars is correct that the choices are sparse and poor when it comes to skinning existing email lists as forums.  We have a stalled, but on-going, project to skin the xen-users mailing list on the Q&A forum on XenProject.org.  Most of the basic functionality exists in the extension we are trying to use, but functions (emailing certain parties who are interacting via the website) do not work as advertised.  The contractor was following up with the extension provider, but atop-to-bottom reorganization of the contracting company has put the effort on hold for the past several weeks until they reboot their services division (supposedly, "next month"; we'll see).
>
> We were approached by a startup last year which had promising forum-skinning technology, but they were both closed source and expensive.  I think that company may have failed already.
>
> There are a handful of options of integrated forum & mailing list (Discourse being one of the most prominent), but they require recreating the mailing list under the auspices of the tool. So the xen-devel mailing list as we know it would have to be abandoned and/or migrated to the new tool.  That represents a potentially large disturbance to existing users, which isn't desirable.
>
> I haven't reassessed the solution landscape in a few months, so maybe it is time to check again.  But I am not hopeful that we will find a good result.
>
> BTW, if you know someone looking for their next FOSS project, feel free to suggest transparent skinning of an email list with a forum interface.  It is a real niche with no good players.

I still not found a good and "all-in-one" solution but I saw this open 
source project: patchwork http://jk.ozlabs.org/projects/patchwork/
Seems interesting, is integrated with mailing list, now seems with 
"basic features" but probably in future it could become great.
I same that many open source project already use it, has someone here 
already tried it in other projects? If yes what do you think?

>
> Russ Pavlicek
> Xen Project Evangelist, Citrix Systems
> Home Office: +1-301-829-5327
> Mobile: +1-301-814-1143
> UK VoIP: +44 1223 852 894
>
> ________________________________________
> From: Lars Kurth
> Sent: Monday, August 31, 2015 1:32 PM
> To: Wei Liu; Fabio Fantoni; Russell Pavlicek
> Cc: xen devel
> Subject: Re: [Xen-devel] Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?
>
> Adding Russell,
>
>
> On 31/08/2015 15:16, "Wei Liu" <wei.liu2@citrix.com> wrote:
>
>> CC Lars.
>>
>> On Mon, Aug 31, 2015 at 03:46:30PM +0200, Fabio Fantoni wrote:
>>> I saw some discussions about the developer cycle, patch review and how
>>> to
>>> improve.
>>>
>>> Based on what I saw an important thing for improve efficiency and
>>> spending
>>> less time is the way of communication, actual seems only
>>> mailing-list/mails.
>>>
>>> It seems to me that currently has some limits and in many cases takes a
>>> long
>>> time for some specific searches,trouble finding patches that need
>>> attention
>>> etc...
>>>
>>> A good solution I think would be a forum specific for developing with
>>> these
>>> features:
> Fabio, of course the downside is that some developers are quite happy with
> mailing lists. There is also a generational gap: developers that grew up
> with lists prefer lists, developers that grew up with forums prefer forums
> (the same is true for people starting in FOSS with github, which exposes
> forum like functionality). This is a well known problem in many FOSS
> communities.
> http://programmers.stackexchange.com/questions/71148/why-do-programmers-sti
> ll-use-mailing-lists is covering many topics of that debate (without
> getting religious about it).
>
> We did also have a discussion at the 2014 developer meeting, where we
> discussed the high volume of traffic on xen-devel. At the time we decided
> not to split the list and use better tagging (arm, x86, tools, ...).
>
> Russell has evaluated some off-the shelf tooling that would allow bridging
> the gap: unfortunately there is nothing good out there, which works well
> in practice. Google groups, which was designed with list support in it
> also kind of sucks. However, I believe we still have a project with a
> contractor ongoing to try and bridge xen-users with
> http://xenproject.org/help/questions-and-answers.html (such that they
> become mirrors of each other) - I will let Russell give an update. If that
> project gets to the point that the bridge works, that nobody is badly
> impacted, maybe we can consider extending it to other lists.
>
>
>
>>> - light even if with many specific features useful for developing and
>>> compatible with all browser and devices
>>> - have all as forum discussion that is easier to search, access to all
>>> post
>>> etc... now the search is only via web for month (losing link in
>>> different
>>> months) and with mail (if storing thousands of emails per month)
> Actually, this is why provide http://xen.markmail.org/ - it also provides
> some advanced search queries (see
> http://markmail.org/docs/faq.xqy#searchsyntax)
> I can check whether we can configure mhonarc our archiver differently, or
> whether there are other options. Maybe there are better archivers we could
> look at also
>
>>> - possibility to include group or single users (for example
>>> maintainers) to
>>> a discussion (also notify with mails based on specific destination users
>>> settings), better that send mails, faster for search, will avoid also
>>> problem of mails not received, mail address changed etc...
> I guess that would be hard to implement (even scripts/get_maintainer.pl
> has issues). Also of course the drawback is that the entire contribution
> workflow may have to change (it is currently build around git send-email)
>
>>> - good patch "integration", possibility to include/see/download
>>> patches, raw
>>> vision (like the patch sent now with mail with git), add of special tags
>>> etc... This is probably the more difficult thing to do because need to
>>> find
>>> the best way to manage well the patches, including series and ultimately
>>> have a better solution to track, review, comment, etc...
> I am not sure, whether there is any decent git integration with any
> forums.
>
>>> - optionally automatic include maintainer for patch posted, probably
>>> after
>>> loading it on server scanning with a similar to
>>> scripts/get_maintainer.pl
> See above
>
>>> - advanced searching including if is a normal discussion or patch, if
>>> the
>>> user is present on notify list, selection of all tags, for example for
>>> search in patch that are fix or features, is the discussion/patch is
>>> without
>>> reply or with reply older that specified range (faster search of patch
>>> without review, or without recent reply), is closed (about patch if
>>> merged)
>>> or not
> We may be able to do some of this: I am currently working with a company
> called Bitergia which does open source dashboards and analysis of open
> source communities. One of these activities is to model the review process
> for us, such that we can reliable stats.
>
> You can do some of what you need with the xen mark mail search with
> queries such as 'list:xen-devel subject:patch -subject:"Re:"'
>
> There is a problem with identifying stale reviews on mailing lists. Which
> is what I assume you are looking for. You can't tell reliably from the
> list whether
> * a review has ended because the code went into git
> * whether it has been abandoned
> * whether it is waiting to be looked at
>
> Bitergia have been working on a new UI for other projects. A prototype for
> us it at http://projects.bitergia.com/previews/ng/dashboard.html?db=xen :
> the data sources are not quite right, the config is not quite right and it
> does not cover reviews. In any case, you can filter commits by time, repo,
> company, ... The link back to git is currently also not yet working.
>
> A similar view would be available for code reviews: right now, that only
> works for projects that use Gerrit or similar tools. But assuming we can
> model the review workflow for us, it may be possible to create some custom
> searches on that combined database. You can filter by
>
>>>
>>> I did a fast internet search about without find a similar solution, the
>>> only
>>> near thing is probably forum with some specific extension (if exist).
> I don't think there is much today, which is surprising.
>
>>> There are some solutions with part of these goals but lacking in some
>>> important, for example github.
>>> What do you think about this?
>>>
>>>
>>> Thanks for any reply and sorry for my bad english.
> Your English was great!
>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel

Re: Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?

[Ian Campbell]

On Wed, 2015-09-30 at 15:49 +0200, Fabio Fantoni wrote:
> I still not found a good and "all-in-one" solution but I saw this open
> source project: patchwork http://jk.ozlabs.org/projects/patchwork/
> Seems interesting, is integrated with mailing list, now seems with 
> "basic features" but probably in future it could become great.
> I same that many open source project already use it, has someone here 
> already tried it in other projects? If yes what do you think?

I've used it in my role as a u-boot custodian and I think it is "meh". It's
ok but it really requires everyone (i.e. all maintainers) to buy into using
it and to be disciplined about doing so and it does need frequent tending
and gardening otherwise it tends to accumulate cruft.

IME the command line clients leave something to be desired and the workflow
for actually applying a patch from p/w is rather clumsy, in particular
there is no easy way to access git-am's --reject option, other than using a
temporary file.

I don't think it would be a good fit for us.

Ian.

Re: Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?

[Julien Grall]

Hi,

On 30/09/2015 15:02, Ian Campbell wrote:
> On Wed, 2015-09-30 at 15:49 +0200, Fabio Fantoni wrote:
>> I still not found a good and "all-in-one" solution but I saw this open
>> source project: patchwork http://jk.ozlabs.org/projects/patchwork/
>> Seems interesting, is integrated with mailing list, now seems with
>> "basic features" but probably in future it could become great.
>> I same that many open source project already use it, has someone here
>> already tried it in other projects? If yes what do you think?
>
> I've used it in my role as a u-boot custodian and I think it is "meh". It's
> ok but it really requires everyone (i.e. all maintainers) to buy into using
> it and to be disciplined about doing so and it does need frequent tending
> and gardening otherwise it tends to accumulate cruft.
>
> IME the command line clients leave something to be desired and the workflow
> for actually applying a patch from p/w is rather clumsy, in particular
> there is no easy way to access git-am's --reject option, other than using a
> temporary file.
>
> I don't think it would be a good fit for us.

I'm wondering if a tool like Phabricator [1] would help here. It offers 
both interface and command line [2] to review, download a series...

I've just started to use it with FreeBSD and I find very handy for the 
contributors as you can keep track of comment addressed and see 
difference between revision...

I've added Roger who is using it more often than me.

Regards,

[1] http://phabricator.org/
[2] https://secure.phabricator.com/book/phabricator/article/arcanist/

-- 
Julien Grall

Re: Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?

[Roger Pau Monné]

El 03/10/15 a les 21.35, Julien Grall ha escrit:
> Hi,
> 
> On 30/09/2015 15:02, Ian Campbell wrote:
>> On Wed, 2015-09-30 at 15:49 +0200, Fabio Fantoni wrote:
>>> I still not found a good and "all-in-one" solution but I saw this open
>>> source project: patchwork http://jk.ozlabs.org/projects/patchwork/
>>> Seems interesting, is integrated with mailing list, now seems with
>>> "basic features" but probably in future it could become great.
>>> I same that many open source project already use it, has someone here
>>> already tried it in other projects? If yes what do you think?
>>
>> I've used it in my role as a u-boot custodian and I think it is "meh".
>> It's
>> ok but it really requires everyone (i.e. all maintainers) to buy into
>> using
>> it and to be disciplined about doing so and it does need frequent tending
>> and gardening otherwise it tends to accumulate cruft.
>>
>> IME the command line clients leave something to be desired and the
>> workflow
>> for actually applying a patch from p/w is rather clumsy, in particular
>> there is no easy way to access git-am's --reject option, other than
>> using a
>> temporary file.
>>
>> I don't think it would be a good fit for us.
> 
> I'm wondering if a tool like Phabricator [1] would help here. It offers
> both interface and command line [2] to review, download a series...
> 
> I've just started to use it with FreeBSD and I find very handy for the
> contributors as you can keep track of comment addressed and see
> difference between revision...
> 
> I've added Roger who is using it more often than me.

FWIW, I think Phabricator is a good option, it has some features which I
find helpful:

 - Allows upload of patches directly from git using command line tools
(much like git send-email).
 - Has a nice split view of changes.
 - Allows commenting inline.
 - Allows the submitter to take actions on comments (marking them as
done, not possible...).
 - You can create groups of people (like "x86 hypervisor maintainers")
and assign reviews to them.
 - If properly configured Phabricator knows when reviews are committed
and automatically closes them.
 - Detects interactions between patches.

It has drawbacks however:

 - Indentation sometimes is mangled when viewing patches from the browser.
 - Comments/reviews can only be done using the web interface.
 - Everyone would have to switch the workflow, I don't know anyway to
get it integrated with mailing lists.
 - I don't know how much customization/hacking the FreeBSD Phabricator
instance has been beaten with in order to have it behave properly.
 - IMHO it is more suited for a workflow were submitters are also
committers, since patches can be easily accepted by maintainers and
committed by the author. I'm now sure how hard it would be for
committers to fetch all accepted patches and commit them.

Roger.

Re: Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?

[Ian Campbell]

On Mon, 2015-10-05 at 11:32 +0200, Roger Pau Monné wrote:
> 
[...]

> It has drawbacks however:
> [...]
>  - Comments/reviews can only be done using the web interface.

That's a show stopper IMHO.

>  - Everyone would have to switch the workflow, I don't know anyway to
> get it integrated with mailing lists.

This probably is too.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Improve or change devel mailing-list for improve efficiency and spending less time, is this possible?

[Roger Pau Monné]

El 05/10/15 a les 11.40, Ian Campbell ha escrit:
> On Mon, 2015-10-05 at 11:32 +0200, Roger Pau Monné wrote:
>>
> [...]
> 
>> It has drawbacks however:
>> [...]
>>  - Comments/reviews can only be done using the web interface.
> 
> That's a show stopper IMHO.
> 
>>  - Everyone would have to switch the workflow, I don't know anyway to
>> get it integrated with mailing lists.
> 
> This probably is too.

I think so. The FreeBSD community didn't have such a typed review
process before. Some reviews where done in private emails between the
affected parties, some reviews where done in public mailing lists, and
some reviews where done post-commit in the changelog mailing lists.

Switching to Phabricator there also had the nice effect of having a
single place where reviews are done, and developers can do pre-commit
reviews more easily. This is not an issue for Xen, since reviews are
always done pre-commit.

Roger.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel