Re: Fwd: Re: Gambas to Git(Lab) (Adrien Prokopowicz)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Re: Gambas to Git(Lab) (Adrien Prokopowicz)

PICCORO McKAY Lenz
here i anwer the question made by Crist! and make some corrections to the post of Adrien:

Date: Fri, 28 Jul 2017 16:35:44 +0200
From: "Adrien Prokopowicz" <[hidden email]>
To: "mailing list for gambas developers"
        <[hidden email]>
Subject: Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)

about that Adrien said: 
I took a bit of time to think about it, and I think the best workflow for
developing Gambas would be the one that's described in the Git
documentation[0] :

- The master branch is the stable branch : it only contains the latest
stable
   release of gambas. (with tags to keep the previous releases).
- A dev branch, for the development version. (the equivalent of the
current trunk).
- Various branches for work-in-progress features that are not ready at all
(like gb.term.form)
its the most similar workflow, according to my git experience and svn experience.. 
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..
 

For bigger changes and experimental components we create a new branch from
the dev branch,
work on it, and then merge it back in the development branch when it's
ready.
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

 
And when we want to release a new Gambas version, we just merge the
development branch
in master, and create a tag to mark the new release.
exactly!
 

If we need to make a patch release for bugfixes in the meantime, we can
just use the master
branch to get back to the latest stable, and then make the fixes from
there.
If the fix is already done on the development version, we can cherry-pick
it from the dev
branch, and otherwise we can just make the fix on master (or on a
temporary branch), and
then merge master back into the development branch.
its almost like but works
 

but WAITH STILL NEED ENTION MERGE AND PULL PATCHES FROM USERS its important!
this anwers the question made by Cris, lest see:
 
From: Christof Thalhofer <[hidden email]>
To: mailing list for gambas developers
        <[hidden email]>
Subject: Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi,
Assume, Gambas gets bigger and more important and somewhere in the
future there exists a Gambas 3.20 in old distributions like Debian and
Gambas 4.05 in current Ubuntu, each of these versions is "stable".

Assume also there is a security breach introduced in Gambas 3.10 ;-)

How would you insert a hotfix which would lead to stable 3.21 and stable
4.06 in your model? IMO ... that would be impossible.


but WAITH STILL NEED ENTION MERGE AND PULL PATCHES FROM USERS its important!

that feature are not present in the svn, due the svn are limited to developers of the gambas repository.. how will be that?

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.. 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Re: Gambas to Git(Lab)

Adrien Prokopowicz-2
Le Fri, 28 Jul 2017 18:03:37 +0200, PICCORO McKAY Lenz  
<[hidden email]> 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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-devel
Loading...