Re: [Glpi-dev] Branching rules

2016-10-17 Thread Johan Cwiklinski
Hello,

> I think we also need a "Release Manager" ;)
> 
> - create the branch
> - tag the version
> - create / publish the tarball
> - check which commits can go in the branch after a RC.

I'm pretty OK with that.

> And perhaps we also need a "9.1.1" branch
> 
> So only "critical" remaining bugs can go there, and allow dev to
> continue fixing bug in 9.1 branch

Hum... I do not think this is required... Since we only fix bugs in the 
9.1/bugfixes, 9.1.1 can just be tagged once critical fixes will be done.
Waiting for that, we can continue to fix bugs in this branch, 9.1.1 will come 
with a maximum of bugfix, that does not really seem an issue to me.

The only point would be if you're affraid of regression; I'm pretty confident 
on this, but I do not know the project as you do ;)

If you think we should really create a new branch, I can take the RM hat, no 
problem ;)

> BTW, I hope 9.1.1 could be released soon...
> (according to the various bug affecting install/update process)

Indeed, this release should be tagged once network ports stuff have been fixed.

And oh, is there a ticket for those critical things? I guess it has not been 
created (I can do, but I'm unsure I understand the whole issue).

-- 
Johan

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Branching rules

2016-10-17 Thread Alexandre Delaunay
Hello.

This process is actually my responsibility.
But i have temporary less time to make reviews.

I also hope a 9.1.1 release soon but i think we miss a important part in 
network ports to do it.
Could we expect start or mid of next week ? (maybe sooner ?)

For enhance future releases, i'm open to any advises.
Maybe we need to clarify what's we need to do before and for a release.

BTW, ok for a finishing branch name 9.1.1.
Il will be off (still reading mails) for the rest of the week, Johan or you 
could create it ?

I pushed recently an update for the tools/make_release script. I think it's now 
compatible with the current code.
It will avoid errors like incomplete tarballs.

Regards.


- Mail original -
> De: "Remi Collet" <fed...@famillecollet.com>
> À: glpi-dev@gna.org
> Envoyé: Dimanche 16 Octobre 2016 12:07:44
> Objet: Re: [Glpi-dev] Branching rules
> 
> I think we also need a "Release Manager" ;)
> 
> - create the branch
> - tag the version
> - create / publish the tarball
> - check which commits can go in the branch after a RC.
> 
> And perhaps we also need a "9.1.1" branch
> 
> So only "critical" remaining bugs can go there, and allow dev to
> continue fixing bug in 9.1 branch
> 
> So, RM
> - create the 9.1.1 branch from 9.1
> - commit only selected fix in this branch
> - release it from this branch
> 
> 
> BTW, I hope 9.1.1 could be released soon...
> (according to the various bug affecting install/update process)
> 
> 
> Remi.
> 
> 
> ___
> Glpi-dev mailing list
> Glpi-dev@gna.org
> https://mail.gna.org/listinfo/glpi-dev

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Branching rules

2016-10-16 Thread Remi Collet
I think we also need a "Release Manager" ;)

- create the branch
- tag the version
- create / publish the tarball
- check which commits can go in the branch after a RC.

And perhaps we also need a "9.1.1" branch

So only "critical" remaining bugs can go there, and allow dev to
continue fixing bug in 9.1 branch

So, RM
- create the 9.1.1 branch from 9.1
- commit only selected fix in this branch
- release it from this branch


BTW, I hope 9.1.1 could be released soon...
(according to the various bug affecting install/update process)


Remi.


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Branching rules

2016-10-11 Thread Remi Collet
Le 10/10/2016 à 10:04, Johan Cwiklinski a écrit :
>> All old developers know that you must always fix in current version.
>> If it's a new developer it's a mistake of his tutor should have seen the
>> problem.
> 
> New developer or not, having some documentation we can rely on and check when 
> unsure will probably prevent issues.
> That is why I've documented this part.

Indeed, documentation can be useful.

Our previous workflow state the "mentor" role for new contributor (or
"tutor").

This mean any new comer will have to find a "mentor" whom will help him
(explain GLPI framework, CS, workflow...) and will propose him for write
access when he think the new developer is ready.

Of course, git can help for this (simpler than SVN)

I think this role is important, is everyone review the new dev. patches,
it will be hard to have a global view of his work.


Remi.


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Branching rules

2016-10-07 Thread nini.lasson

Le 06/10/2016 à 20:43, Johan Cwiklinski a écrit :

Hello,

Hi,



I don't understand this "new" workflow because it's not one (it's the
same since very long time)

This is nothing new, and this sounds logical to me.


For bug in stable version => correction in stable bugfix and master
version (with evolution if needed)

The important point here is just the order. We should not fix bugs in master 
and get the fix back in bugfixes; and that is not clear at all actually. Take a 
look at submitted PRs, you'll see that bugs are fixed in master and asked to be 
reintegrated into master... That is what I want to get explained in details.

Who do that?
All old developers know that you must always fix in current version.
If it's a new developer it's a mistake of his tutor should have seen the 
problem.


Regards,
Yllen



For evolution   => only done on master

You know the version to do by the version indicated by the requester.

So, we totally agree; the documentation is just a try to formalize procedures.

Regards,




___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Branching rules

2016-10-06 Thread Remi Collet
Le 06/10/2016 à 08:08, Moron, Olivier a écrit :
> Hello,
> 
> Ok for me, sounds good, apart the word “backport” which seems to be
> bizarre when speaking about 9.1/bugfixes -> master (I would prefer
> cherrypicked or ported), and also for master -> master (I would prefer
> Pull Request?). For me “backport” means a port of a modification (fix or
> evolution) into a previous version, and not into a future version.

I Agree about confusing wording.

> Regards,
> 
> Olivier
> 
>  
> 
> -Original Message-
> From: Glpi-dev [mailto:glpi-dev-boun...@gna.org] On Behalf Of Johan
> Cwiklinski
> Sent: Wednesday, October 05, 2016 9:44 PM
> To: Liste de diffusion des developpeurs GLPI
> Subject: [Glpi-dev] Branching rules
> 
>  
> 
> Hello all,
> 
>  
> 
> There is one "important" point I've documented on the dev doc, regarding
> to branching for features and bugfixes.
> 
>  
> 
> What I propose is:
> 
> - to fix a bug on the stable release, the work must be done on the
> 9.1/bugfixes branch (for now), and must be merged back to this one; and
> then backported to master
> 
> - to fix a bug on the next release (master), the work must be done on
> master and backported to master only.

New feature ?  (master of course)

Which also mean, beta/RC should be tagged from the version branch, as
this means the version enter "stabilization" phase, and so, feature freeze.

ie: at some point in the future

- branch 9.2/bugfixes
- tag 9.2RC1 from it
- master becomes 9.3dev

We probably also need a "String freeze" for translators.

Remi.

> 
>  
> 
> This workflow should prevent parts of master code to be backported to
> the bugfixes branch, what would be a real issue.
> 
>  
> 
> For features, well, this concerns only the next release, and that will
> reach master only; no problem.
> 
>  
> 
> Do you agree with this workflow rules? Have you any comments/suggestions?
> 
>  
> 
> For the short story, github make possible to change the destination
> branch once a PR has been opened, so it should not be an issue... But
> changing from master to 9.1/bugfixes will try to add other commits from
> master... Contributor will have to rebase on the correct branch on his
> side. Sounds like a GH bug (or thing I do not understand -- that's the
> same, isn't it? ;)).
> 
>  
> 
> I just want that to be clear for everyone.
> 
>  
> 
> Regards,
> 
> -- 
> 
> Johan
> 
>  
> 
> ___
> 
> Glpi-dev mailing list
> 
> Glpi-dev@gna.org 
> 
> https://mail.gna.org/listinfo/glpi-dev
> 
> 
> 
> ___
> Glpi-dev mailing list
> Glpi-dev@gna.org
> https://mail.gna.org/listinfo/glpi-dev
> 


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev