* Cédric Krier: " Re: [tryton-dev] Faster contribution" (Wed, 19 Nov 2014
  15:24:40 +0100):

> On 19 Nov 14:59, Mathias Behrle wrote:
> > * Cédric Krier: " Re: [tryton-dev] Faster contribution" (Wed, 19 Nov 2014
> >   12:44:15 +0100):
> > 
> > > On 19 Nov 12:12, Mathias Behrle wrote:
> > > > * Cédric Krier: " Re: [tryton-dev] Faster contribution" (Wed, 19 Nov
> > > > 2014 11:27:25 +0100):
> > > > - It should still be possible to track issues and reviews in the commit
> > > > message.
> > > 
> > > review is appended to the patch.
> > > issue depends if the submitter add it or not.
> > 
> > So this is dropped as a requirement?
> 
> It will depend of the issue.
> If the contributor will only provide a patch for an issue core
> developers find it needs one, it will be requested as comment.
> 
> > > > - It should be possible to use a specified name and email address for
> > > > the commit message.
> > > 
> > > Such contributor will have to use their preferred email address to login
> > > in rietveld. And they will have to set their real name.
> > 
> > I doubt that will work. Not everyone wants to register every address (and
> > especially addresses for this usage) at Google.
> 
> That's another topic. The move from appspot to self hosting is there
> since more than 3 years and nobody ever takes any steps, so we can guess
> it is not really an issue.

It seems to be an issue, even for the usage of appspot itself. If I understood
correctly, Sharoon stated at TUL, that it is impossible for him to participate
on reviews, because there are conflicts between mail adresses. Of course it
would be best, if he would jump into this discussion to explain exactly the
matter.
 
> https://bugs.tryton.org/issue2177

I think, that no one took it is rather a sign of limited resources than not
being it an issue. Which raises oviously the question: why shouldn't we use an
external infrastructure, where we get all this for free?

As I already stated at TUL, I am not a big fan of making global players to
monopolists by reinforcing them in getting dependent from them. Nevertheless I
would appreciate a lot a solution, that takes the best from the two worlds:

If we could get away by using github just as a frontend, from which we pipe all
requests to the project owned infrastructure
- we had a very comfortable interface for easy contributions
- we would be more known and better reachable, because github is just what it
  is: a huge place of code and coders
- we nevertheless would be masters of our infrastructure and such completely
  independet
- this would just be an additional way to get into contact with and
  contribute to the project doing no harm in keeping all current procedures
  alive
 
> > > > Additional open questions for me with the proposed setup:
> > > > 
> > > > - Until now I am missing the procedure, how the review gets into trunk.
> > > 
> > > One core dev has to take it.
> > 
> > That doesn't explain, how the procedure should work.
> 
> A core dev will take a patch and push it.
> As contributor you don't have to care of any of this.

As long as this will be in the following way, this could save work for all of
us:

- Lets get an additional field for the commit message (or misuse the current
  description for it). The final commit message including bug and review tags
  should go into it.
- Core dev could integrate the patch with hg import directly.

which would save all this export and attaching to bugs work.
 
> > > > - It should at least exist an additional field for the mail address.
> > > > Since we are (still) tied to google for authentication, you don't want
> > > > necessarily take the google registered address for the commit message.
> > > 
> > > Use a google account for your preferred email address. I think it is the
> > > best way to do it as this will ensure we will have a valid address.
> > 
> > I think this could be another quite substantial barrier for contribution at
> > all.
> 
> Too bad for them. At some point, ...

I agree about 'at some point'. I doubt, this point is the same for you and
me...;)

> ...we must realize that people who are
> nitpicking to contribute, are losing but not the project. If you can fix
> an issue and you don't do it, it is bad for you not for us.

It is bad for all and misses the advantage of being OpenSource and getting
stronger by contribution.

> > I found another point to add:
> > 
> > - It should be able to work on a tree of repos (this being a feature of the
> >   current setup and not being possible on github AFAIK). 
> 
> Such cases are for big changes (so out of cusual contributor) and we
> already have a good workflow for that for the core developers.

Of course. But the subject is about 'Faster contribution', not only for casual
contributots.


-- 

    Mathias Behrle
    MBSolutions
    Gilgenmatten 10 A
    D-79114 Freiburg

    Tel: +49(761)471023
    Fax: +49(761)4770816
    http://m9s.biz
    UStIdNr: DE 142009020
    PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

Attachment: pgpt8lYvxvquh.pgp
Description: Digitale Signatur von OpenPGP

Reply via email to