commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [GitHub] commons-math pull request: Updated the example documentation for t...
Date Fri, 03 Oct 2014 14:43:21 GMT
Gilles, Luke, Phil,

I respect what you are saying.  All I'm saying is that I think using Git to it's full potential
will be more attractive and less confusing to future contributors.  I'm really not trying
to lobby strongly for this though.  I just shared my thoughts on it in case the move to github
triggers others to start asking the types of questions / comments that we just saw.

- Ole

On 10/03/2014 06:42 AM, Luc Maisonobe wrote:
> Hi all,
> Le 03/10/2014 12:17, Gilles a écrit :
>> Hi.
>> On Thu, 02 Oct 2014 15:35:53 -0500, Ole Ersoy wrote:
>>> On 10/02/2014 02:18 PM, Phil Steitz wrote:
>>>> On 10/2/14 11:33 AM, Ole Ersoy wrote:
>>>>> Hi,
>>>>> On 10/02/2014 11:34 AM, Gilles wrote:
>>>>>> Hello.
>>>>>> On Thu, 02 Oct 2014 10:51:53 -0500, Ole Ersoy wrote:
>>>>>>> Hello Luc, Gilles, and Benedikt,
>>>>>>> I'm here :).  From my limited github experience, I do think most
>>>>>>> contributors do their communication directly through github.
>>>>>> "Commons" contributors?
>>>>> I should have clarified.  Just github users and contributors in
>>>>> general.  A popular pattern I see for github repository projects
>>>>> is that developers keep their pull communication with the pull,
>>>>> design (etc.) discussions in issues, and support on
>>>>> stackoverflow.  So I'm thinking that future / potential
>>>>> commons-math contributors might expect this type of pattern.
>>>>>>> I've
>>>>>>> seen a lot of projects use issues for discussion.  I personally
>>>>>>> like
>>>>>>> this, because it makes it easy to get up to speed on design
>>>>>>> decisions
>>>>>>> and project history.
>>>>>> Perhaps it's a better way.  But it's not (yet) the official way,
>>>>>> which
>>>>>> is this ML.
>>>>> Sure.  I just wanted to mention it since github users that are
>>>>> watching the project will get more information without having to
>>>>> subscribe to the mailing list.
>>>>> Also I think what Benedikt was saying was that I might be someone
>>>>> who does not actually know about the mailing list, so if
>>>>> communication goes out to me on the mailing list WRT my pull
>>>>> request, I might miss it.
>>>> The problem is that if any substantial design discussion happens
>>>> *outside* the ML, those who *are* subscribed to the list will miss
>>>> *that*.
>>> Sure - but in all fairness, it's as simple as going to the github
>>> repository and clicking watch.  The other benefit is that now the
>>> notifications will be for commons math only.
>> ?
>> We _have_ to be subscribed on this ML to contribute to this project.
>> Thus we get all the (not necessarily interesting to everyone) posted
>> here, and _in addition_ we would get message from yet another source.
>> That's no improvement. Unless things have to get to get worse before
>> they get better. ;-)

>>>> A core principle of ASF projects is that everything
>>>> happens in the open, is archived and easily accessible to anyone
>>>> interested in getting involved in a project.
>>> This will become even more true if github issues are used.  From a
>>> reading perspective the github format is cleaner looking than
>>> markmail, etc.
>> IMHO, the readability of the archive is not the most important point.
>> It is there for reference purpose. Questions are: Where is the "official"
>> record of the project and where do discussions and decisions take place?
>> The current answer is "here".
>>>> The "if it did not
>>>> happen on the list, it did not happen" principle is really just to
>>>> ensure that.  If we start having design discussions outside the
>>>> list, to figure out what is going on / has gone on, people will have
>>>> to go looking around the internet, rather than just looking at the
>>>> list archives.
>>> Everything is tied to the repository.  All the information is in one
>>> place.  That's usually a plus.
>> Only if we drop everything that would be a duplicate of the functionality
>> available on that other forum.
>>>> This is one reason we have traditionally liked to
>>>> have design discussions on the list, rather than in JIRA tickets and
>>>> why JIRA comments are in any case forwarded to the list.
>>> Sure - honestly I'm just trying to be helpful and suggest a few
>>> things that will make things even simpler while improving the utility,
>>> uniform accessibility, visibility, and marketability of commons math
>>> activity.
>> Thanks for trying to help. However, you might have more luck to create
>> things that do not exist yet rather than try and change what exists.
>> [From my own experience. :-} ]
>>> Since git is a more social platform, it may make sense to
>>> take advantage of more of its features.
>> In practice, you may be right; but in principle, I don't agree.
>> "git" provides the means to decentralize while "github" is by essence
>> a centralizer.
> There are two separate things: discussing features and providing patches.
> Discussion must be on the list. This is Apache way of doing things and
> it is where people will look at. It is one of the few things that are
> mandatory at Apache. Someone said once: "if it didn't happen on the
> mailing list, it didn't happen" (most probably one of Apache early
> founders).
> Git and its decentralized aspects improve on how contributors can
> provide patches. They can experiment ont their own development setup,
> and once they are happy with it they can trigger a pull request. I
> sincerely think this is really a good thing and it allows these people
> tog et involved more quickly. It also seems more fair to me since Git
> allow to have a separate author and committer, so new contributors get
> the credit they deserve more efficiently than with subversion, where
> only the committer name is automatically preserved.
> So you can for sure use GitHub for the pull request, it's great!
> However, the mailing list remains the main discussion place.
> best regards,
> Luc
>> Best regards,
>> Gilles
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message