[Gambas-devel] Fwd: Re: Gambas to Git(Lab)

[Adrien Prokopowicz]

Le Fri, 28 Jul 2017 18:03:37 +0200, PICCORO McKAY Lenz  
<mckaygerhard at ...176...> a écrit:

> but please mantain a firm-name to the branches! like gb.xx.yy.dev
> i mean added last word ".dev" at the end to enphasis the devel of that  
> componente, that due git can mantain history of >the artifact..
> the history of that branchs are important due must help to other  
> developer to see in the history how the problem are >resolved in the  
> time line..

You mean adding ".dev" to help seeing this is an in-development branch ?  
Because
Git does not care what your branches are named (besides master), so I  
don't see
how it helps Git "maintain history"…

Also, you have to see the experimental branches as temporary ones. When  
you are done
with your feature, you get it merged into the development branch (without  
squashing
the commits of course !), and then you delete the branch.

 From experience, I can say that you do not want old branches laying around  
or it will
become an huge mess in no time. Moreover, in the rare case you want to  
consult the
history, looking at the file/directory's history is easier than looking  
for the history
of a branch. So there is no point in keeping them, at least for our case.

> again in that case, the devel branch must named gambas3-devel and the  
> experimental gambas3-experimental
>
> so gambas<X>-<type> where X are the mayor release, and tyope  the  
> working development branch type

There wouldn't be an "experimental" branch, but one for each non-ready  
feature.

> this anwers the question made by Cris, lest see:
>but WAITH STILL NEED ENTION MERGE AND PULL PATCHES FROM USERS its  
> important!

No caps needed there, it's not the end of the world.

With this workflow, user-submitted merge requests (or pull requests in  
GitHub terminology)
are managed just like with the "internal" experimental branches.

The user just has to fork the repository to its own, branch from the  
development
version, work on their own branch, then submit a merge request to merge  
their
branch back in the development version. If the code is approved, then it  
gets
merged and done. :)

> well in github/gitlab, there's a feature that limits the pull request  
> and merge request to the already commiters!
> users can request also joint to propose a pull reques..
>
> if you guys dont do that, maybe the pull repo will be like the  
> codeigniter or like the owncloud, a large pull request of >issues..

I'm not sure I understand, you're afraid that there may be too many pull  
requests ?
First, I think this if a false problem. Not only contributions are very  
welcome,
but both GitLab and GitHub provide tools to handle big amounts of pull  
requests.

An example of project with lots of contributions is Rust[0] : they've got  
like 20
pull requests in the last 7 days (not counting the closed ones), and  
because they
properly tagged everything, I know what every pull request needs, and from  
who, even
if I have no idea what they actually are about.

Also, making users ask permission to open merge requests make no sense at  
all.
A merge request (as its name implies) is already a request from an user to  
merge
code in the main repository (with code review from the maintainers). So  
they would
have to make a request to make a request to merge code ? :-)

[0] https://github.com/rust-lang/rust/pulls
-- 
Adrien Prokopowicz