RFC: Move Sparse development to github

RFC: Move Sparse development to github

[Dibyendu Majumdar]

Hi,

I would like to propose moving Sparse development to github. The model
I would like to propose is as follows:

1. Development should occur in the github hosted repository.
2. When a release is cut it can be merged into the current Sparse repository.
3. Bugs and enhancement proposals should be managed through github issues.
4. My suggestion would that for enhancements a simple majority voting
should be adopted to ensure that features go in because Sparse users
want them.
5. I would also suggest separating out the testing infrastructure to
another repository so that more people can help with testing. I would
be interested in helping with the testing infrastructure as I believe
this will ease a lot of the pain experienced today with making
changes.
6. I also would like to see a multiple committer model for development
so that someone like Luc who is making significant contributions has
commit access.
7. Releases ought to be time based - i.e. a release must be cut every
three months or six months - with the current feature set.

I think moving development to github and adopting a multi-committer
model will significantly improve things. Changes could be done faster,
and contributors will be more motivated by having ownership.

I think this might be a controversial topic - so apologies for raising
it but having observed the process for the past six months I do think
change is necessary.

Regards
Dibyendu

Re: RFC: Move Sparse development to github

[Christopher Li]

On Thu, Aug 10, 2017 at 6:58 AM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> Hi,
>
> I would like to propose moving Sparse development to github. The model
> I would like to propose is as follows:

It does not need to be move from the release stand point of view.
I already have an github account and github repository of sparse.

I can merge the merge request from github (not using the github UI though).
The merge will reflect on github. That should satisfy most of your
points here.

A lot of time is spend on the discussion and figure out what is the
right thing to do. I still like the review before commit model. If Luc
want to make this is clear this is a git pull request I want this pull.
It be pull rather quickly using the current master model. A lot of time
I need to clarify weather the patch is for release or for view.

I can sync the master to github every time I push to korg. That part
is easy.

I am not a big fan of using the github UI for merge though. I can read the
github issue request there fine.

What you are really asking is having Luc on github has his own
sparse tree. Not just patches.  I totally support of that too. I would be
happy to pull from his tree.

I still prefer the review and merge model for release though.

Thanks

Chris

Re: RFC: Move Sparse development to github

[Luc Van Oostenryck]

On Thu, Aug 10, 2017 at 11:58:30AM +0100, Dibyendu Majumdar wrote:
> Hi,
> 
> I would like to propose moving Sparse development to github. The model
> I would like to propose is as follows:

I'll want to first add a few things.

* 'sparse' is a kernel.org:Linux Foundation project and I doubt it's
  official version will be hosted elsewhere (but I may be wrong, I dunno).

* We need & want to comply with the 'Developer certificate of origin',
  the 'Signed-off-by' thing.

* Current sparse developers are subcribed to the mailing list and
  are used to do/read discussion via email.

* I'm much more efficient at writting comments, discuss, ...
  with my $EDITOR than using any web UI. I guess than I'm far from
  being alone.

On the other hand:

* I don't see any problem having a kind of official mirror on github

* I'm very fine to take patches via pulls on github but:
  - see the certificate of origin heer above
  - discussions still need to be done via email

* I understand that sending patches via email can, for some, be
  and awkward process
  I would be fine for those people to forward pacthes to the ML
  so that the patches can be discussed about in the usual way.
  But I would not write for them something like the cover letter
  and such. I would only be able to do this if the volume is low.

* Same for bug reports and suggestions

> 4. My suggestion would that for enhancements a simple majority voting
> should be adopted to ensure that features go in because Sparse users
> want them.

I don't see a real need for that.
If someone has a features and wrote the patches, those patches should
be submitted, reviewed, ... as usual and then pushed to master.
I'm being a bit naive or optimistic here, but I think that for most
cases the usefullness of a features is obvious and would certainly not
need any kind of votes. If the features has some negatives aspects then
of course, it's the usual work to balance things and make the best choice.

Also, for technical matters, I don't believe in votes. Only he technical
merrits should count.

> 5. I would also suggest separating out the testing infrastructure to
> another repository so that more people can help with testing. I would
> be interested in helping with the testing infrastructure as I believe
> this will ease a lot of the pain experienced today with making
> changes.

As is, I don't see what would be the benefit, on the contrary separating
them would be a disadvantage.
Mind to clarify a bit more what you have in mind, it's reasons?

> 7. Releases ought to be time based - i.e. a release must be cut every
> three months or six months - with the current feature set.

Yes, or at least something very reasonable.
6 months seems a maximum to me.
 
I'm also very much in favor of being able to cut a release at any time
using the current master branch.

> I think this might be a controversial topic - so apologies for raising
> it but having observed the process for the past six months I do think
> change is necessary.

No problem.
And yes, the process is far from good, at several levels.

-- Luc

Re: RFC: Move Sparse development to github

[Dibyendu Majumdar]

Hi Luc,

I get the feeling that this is a non-starter for people here, so I
won't be continuing the discussion anymore. But my responses to your
points are below.

On 11 August 2017 at 01:11, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> On Thu, Aug 10, 2017 at 11:58:30AM +0100, Dibyendu Majumdar wrote:
>> I would like to propose moving Sparse development to github. The model
>> I would like to propose is as follows:
>
> I'll want to first add a few things.
>
> * 'sparse' is a kernel.org:Linux Foundation project and I doubt it's
>   official version will be hosted elsewhere (but I may be wrong, I dunno).
>
> * We need & want to comply with the 'Developer certificate of origin',
>   the 'Signed-off-by' thing.
>

Okay I don't know if these are deal breakers or if any other Linux
project is using github.

> * Current sparse developers are subcribed to the mailing list and
>   are used to do/read discussion via email.
>
> * I'm much more efficient at writting comments, discuss, ...
>   with my $EDITOR than using any web UI. I guess than I'm far from
>   being alone.
>

Sure I understand. Github appears to support email interaction with
the issues system but I am not sure it will be as convenient as it is
today.


> On the other hand:
>
> * I don't see any problem having a kind of official mirror on github
>

That is not very useful in my view.

> * I'm very fine to take patches via pulls on github but:
>   - see the certificate of origin heer above
>   - discussions still need to be done via email
>
> * I understand that sending patches via email can, for some, be
>   and awkward process
>   I would be fine for those people to forward pacthes to the ML
>   so that the patches can be discussed about in the usual way.
>   But I would not write for them something like the cover letter
>   and such. I would only be able to do this if the volume is low.
>
> * Same for bug reports and suggestions
>

I don't really see the benefit of that as you will be substituting one
git repository with another. In my view the advantages of github are
that it brings together other features in one easy to use package and
the features work well together.

>> 4. My suggestion would that for enhancements a simple majority voting
>> should be adopted to ensure that features go in because Sparse users
>> want them.
>
> I don't see a real need for that.
> If someone has a features and wrote the patches, those patches should
> be submitted, reviewed, ... as usual and then pushed to master.
> I'm being a bit naive or optimistic here, but I think that for most
> cases the usefullness of a features is obvious and would certainly not
> need any kind of votes. If the features has some negatives aspects then
> of course, it's the usual work to balance things and make the best choice.
>
> Also, for technical matters, I don't believe in votes. Only he technical
> merrits should count.
>

Fine, but I think voting is a good way to prioritize things.

>> 5. I would also suggest separating out the testing infrastructure to
>> another repository so that more people can help with testing. I would
>> be interested in helping with the testing infrastructure as I believe
>> this will ease a lot of the pain experienced today with making
>> changes.
>
> As is, I don't see what would be the benefit, on the contrary separating
> them would be a disadvantage.
> Mind to clarify a bit more what you have in mind, it's reasons?
>

Well I was mainly thinking that testing repository could be opened up
to more people and allow direct commit access to people interested in
adding tests.

Regards
Dibyendu

Re: RFC: Move Sparse development to github

[Luc Van Oostenryck]

On Sat, Aug 12, 2017 at 4:04 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> Hi Luc,
>
> I get the feeling that this is a non-starter for people here, so I
> won't be continuing the discussion anymore. But my responses to your
> points are below.

I'm certainly interested to understand what are the problems for others
and try to improve things when possible.

>> On the other hand:
>>
>> * I don't see any problem having a kind of official mirror on github
>
> That is not very useful in my view.

I agree. But it would already give a more visibility than now.

>> * I'm very fine to take patches via pulls on github but:
>>   - see the certificate of origin heer above
>>   - discussions still need to be done via email
>>
>> * I understand that sending patches via email can, for some, be
>>   and awkward process
>>   I would be fine for those people to forward pacthes to the ML
>>   so that the patches can be discussed about in the usual way.
>>   But I would not write for them something like the cover letter
>>   and such. I would only be able to do this if the volume is low.
>>
>> * Same for bug reports and suggestions
>
> I don't really see the benefit of that as you will be substituting one
> git repository with another. In my view the advantages of github are
> that it brings together other features in one easy to use package and
> the features work well together.

Yes, it's not much beneficial, I agree.

>>> 4. My suggestion would that for enhancements a simple majority voting
>>> should be adopted to ensure that features go in because Sparse users
>>> want them.
>>
>> Also, for technical matters, I don't believe in votes. Only he technical
>> merrits should count.
>
> Fine, but I think voting is a good way to prioritize things.

Maybe, and sorry if this seems like an easy canned response but
the development is done by volunteers, on their free time, like I suppose
you do for your dmr_C project. It's one thing to say "oh yes, I also think
this is a good idea/something that we need badly", it's another one
to have a list of prioritized features. How binding would this list be?

Even, having a list of bugs doesn't help much to solve these bugs,
prioritized or not.

> Well I was mainly thinking that testing repository could be opened up
> to more people and allow direct commit access to people interested in
> adding tests.

I think that simply saying on the mailing list something like:
"hey look at this piece of code I have a problem with. I think
that this or that is wrong" would already be a good thing,
like you already did.


I'm sorry if all this seems to go against what you're proposing.
I'm very sure though that we have the same goal in mind:
improve sparse and make good use of it.

-- Luc