Re: [Banshee-List] Report on pending patches Issue 01/2011

[olivier dufour <olivier duff gmail com>]

Hey,

me again ;)

I talk with Alan and here come a good idea. To help in patch submit process. Most of issues are well known:

1. Mostly typo

2. Forget to dispose something which need dispose

3. ...

 

Why not add a new rule in make?

make format-test

to test format of file with a tool as awk or use monotorrrent autoformat. But I do not know if the format is link to the project file and if it can be scripted...

For other errors, like disposing file, stream,... we can use gendarme.

The goal is to not waste time on typo/coding guid line...

Do you think it is doable ?

Olivier Dufour

On Sat, May 21, 2011 at 8:23 PM, Frank <funtastix googlemail com> wrote:

I like these ideas and I hope as well that everyone sees the attempt
to find ways to better contribute to/support the project and create
less/easier maintainer's work. Gabriel is not even full time on
Banshee, no one is. But that's common in open-source project I assume.
Having developers full time on the project before was luxury.

As I said, I like the ideas, but I don't know if some of them work so
well. Here are the thoughts that popped into my mind:

1. more maintainers and "experimental" less tested patches:

a) of course that's desirable! :)
b) When I read about Banshee one thing that is common is reading about
stability issues. As much as I also want my own patches integrated, I
think at the moment stability should rather increase and I think
patching with code that has less critical review and fewer tests could
go the exact other way. On the other hand development is on an
unstable branch (master) and it could make sense to develop this way
if there was enough time given before releases to "clean up" bad
commits.

2. an experimental branch with more maintainers:

a) I really like that thought. I actually have all my patches
accumulated in my own experimental branch and run banshee on that
build to test for stability. I would show clashing code and corrupt
builds as well. Furthermore, and maybe most important, it could give
less savvy users a way to access the latest patches and test them
easily, as building is easier than patching.
b) As for testing I could even imagine to provide a script that a
average user can use to revert certain patches (and then rebuild) to
test for specific issues.
c) branches/experimental branches for big code changes would be great,
as I know it would ease it to participate on such changes if the main
branch developer for that issue needs help. Pulling the branch and
sending a patch proposal for that branch to the developer would be
nice. I am thinking something like the merge-requests on
gitorious/github.

In the end the maintainer's would hopefully need to review less and
just cherry pick more and it would open up ways to involve less savvy
users that are willing to test the latest tech.

Frank

PS: I have gotten the feeling that the original mail to this thread
was appreciated, so I will keep an eye on it and try update that list
every now and then.

On 21 May 2011 23:16, olivier dufour <olivier duff gmail com> wrote:
> Hello,
> I think this is a small part of an iceberg that we face off.
> The main issue is that banshee (as a lot of other open source project) lakes
> of maintainers.
> Aaron have new job and is not anymore full time on banshee.
> So Gabriel is the only one who have a full time job on banshee and he can
> not manage all by himself.
> I know that there is other maintainer but they have not enough time to
> manage all the patch. Everybody have a real life out there which take a lot
> of time.
> So to save time to Gabriel (& other maintainers), I think to 2 things to
> help on that :
> 1) include other maintainers smoothly (I see very skilled devs out there:
> Alex, Alan, ...) who can help Gabriel in the task of reviewing patch and
> include them on git and common if a developer commit a bad patch we can
> revert. git is here for that !
> 2) Create an unstable/lab git fork where we have more commiters which can
> add patch reviewed by them.
> For big refactor (gtk3, gst#, ...) we can have dedicated branch in it. So
> every body can share code on it.
> With a build bot we can provide a build for advance users to test and
> provide feedback.
> After that, main maintainer can cherry pick good commit or revert bad ones.
> The gitorious banshee community extension (bce) project is great
> for extensions but we can not share patch on the core on it.
> PS: do not take this mail a critic against management of the project but as
> a research to help project to have better organisation to avoid a such
> quantity of patch unreviewed.
> If you have other/better ideas to improve organisation, you are welcome.
> Olivier Dufour
>
>
> On Fri, May 20, 2011 at 2:53 PM, Michael Martin-Smucker
> <mlmartin13 gmail com> wrote:
>>>
>>> ... This finally motivate me to go through all unreviewed patches,
>>> analyse their current state and compile the following report to help
>>> get those "almost-there" issues to make their final steps.
>>
>> Wow, that was no small task!  It's great that you put so much effort into
>> it -- hopefully it helps the process along.
>>
>>>
>>> * This is a controversial patch that needs a maintainer's decision
>>> and/or a last review/commit. (I like it)
>>> [https://bugzilla.gnome.org/show_bug.cgi?id=608879]
>>> Type ahead activation without requiring '?' key press (Normal /
>>> enhancement)
>>> --> [https://bugzilla.gnome.org/attachment.cgi?id=162720action=diff]
>>> (348 days) Type ahead activation without requiring '?' key press
>>
>> I went ahead and marked this one 'needs-work.'  Personally I love the
>> behavior in the patch, but I doubt maintainers will accept it without at
>> least a preference option to use Banshee's regular keyboard shortcuts.
>>  Also, it doesn't seem to apply to master anymore.
>> Michael
>> _______________________________________________
>> banshee-list mailing list
>> banshee-list gnome org
>> http://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
>
>
> _______________________________________________
> banshee-list mailing list
> banshee-list gnome org
> http://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)
>
_______________________________________________
banshee-list mailing list
banshee-list gnome org
http://mail.gnome.org/mailman/listinfo/banshee-list  (unsubscribe here)