Github branches - Commit policy

Discussion corner for Developers of Serendipity.
Lux
Regular
Posts: 764
Joined: Fri Aug 12, 2005 4:36 pm
Location: Grüt, Zürich, Switzerland
Contact:

Re: Github branches - Commit policy

Post by Lux »

yellowled wrote:
Lux wrote:Currently I see at least three types of "users":
* Developers need access to everything
* Testers need access to betas and fixes
* Endusers need access to stable (and sometimes to fixes)
Agreed?
Yes, but not all of those need a seperate branch. Most end users probably don't use a git checkout, so they could just use release zip files (we can do those pretty confortably on GitHub as well, we don't need to wait for SF).
Yes, I know.

But honestly, it would be much easier to update for end user if only a diff would be transferred. This is what Git does perfectly well.

But agreed, there are not many endusers that have shell access to their web directories.

On the other hand, if I find a bug in stable, I do not want to wait for it to be fixed in the next dot-release, even if it is not a critical one. (The criticals would be fixed immediately and a dot-release would be published).
yellowled wrote:That leaves us with devs and testers. Devs usually “need” (I think “prefer” is the better term) the current state of development. Testers usually need the upcoming stable. If I'm not mistaken, this could be done with our current setup (master = current state, 2.0 branch = next stable) – but testers using a git checkout would need to use the 2.0 branch, not master.
Yes!
yellowled wrote:What that leaves us with is whether people (meaning devs or testers) are more used to having the current state in master or not, right? :)
Yip.
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: Github branches - Commit policy

Post by garvinhicking »

Whenever we fix a bug in master ("dev"), we also backport it to the branches we support, that was part of my initial commit policy idea (and how we actually do it). So our devs commit it to both the 2.0 branch and master.

That means testers will get the fix instantaneously, no matter if they use 2.0 or master, by doing a "git pull" only.
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: Github branches - Commit policy

Post by yellowled »

Lux wrote:But honestly, it would be much easier to update for end user if only a diff would be transferred. This is what Git does perfectly well.
I believe (I might be wrong) most end users get a zip file from s9y.org (via SF) and upload that via FTP or ssh.
Lux wrote:On the other hand, if I find a bug in stable, I do not want to wait for it to be fixed in the next dot-release, even if it is not a critical one.
But that means you are suggesting another branch.

As of now, we have two branches which contain the 2.x flavour – master and 2.0. master is the current state (i.e. it could break any time), I don't think you'd want to use that in production. 2.0 is the upcoming stable release (currently 2.0, very soon 2.0.1) – you don't want to use that, either, because it will develop slower. I get why you want that, and it's very valuable to have testers like that, but if I understand you correctly, you would want another branch …?

YL
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: Github branches - Commit policy

Post by yellowled »

garvinhicking wrote:So our devs commit it to both the 2.0 branch and master.
If they don't forget it. :roll:

YL
onli
Regular
Posts: 2822
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: Github branches - Commit policy

Post by onli »

I just stumbled upon Ians announcement-hint in http://board.s9y.org/viewtopic.php?p=10442456#p10442456 and feel it is really not a good thing. A bugfix should not introduce such new behaviour, I think. Without blaming anyone, just to know for the future: Do we agree that this feature should have only been pushed to master, and thus have only been part of a 2.1?
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: Github branches - Commit policy

Post by yellowled »

onli wrote:Do we agree that this feature should have only been pushed to master, and thus have only been part of a 2.1?
I think this is just part of us all being new to and kind of unclear about the commit policy and the versioning scheme introduced with 2.0. It's an adjustment period. I'm pretty sure there's more stuff in 2.0.1 which is technically not a bugfix. Also, I think we wanted this in 2.0 and kind of forgot about it. :wink:

Also something to consider: with our “usual” release frequency, 2.1 is quite a ways away, which is fine given the size of our dev team. However, limiting new features to minor releases only and only doing bugfixes in patch releases would result in us “keeping” new features from users for quite a while. We might want to lighten up on that policy a bit, at least for smaller features. Otherwise, we might at some point push people to using master checkouts in production.

YL
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: Github branches - Commit policy

Post by Timbalu »

onli wrote:Do we agree that this feature should have only been pushed to master, and thus have only been part of a 2.1?
Literally YES, I assume!
And we really should fasten up in Development, so 2.1 should be out this year. :)
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: Github branches - Commit policy

Post by garvinhicking »

I must admit I don't fully understand if there's a problem with this? If it screws up something, then yeha, we made a mistake.

But as for the intention of it: I mean sure, it's not a bugfix, but it was a thing that looked capsulated to me and bring a feature that we'd want out of the door ASAP.

You are right though, we mixed up "fixing a bug" and "pushing new features to the users". In the future we definitely need to talk about whether we really want to add "small features" in a point release, thanks for bringing this up.

Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: Github branches - Commit policy

Post by yellowled »

garvinhicking wrote:You are right though, we mixed up "fixing a bug" and "pushing new features to the users". In the future we definitely need to talk about whether we really want to add "small features" in a point release, thanks for bringing this up.
It is purely a question of definition, I think. If we want to adhere strictly to semver then this would maybe not even have been part of a minor version. I don't stricly object to that, but as Ian states correctly, adhering strictly to semver would mean we'd have to speed up our release process.

I'm not sure if we really want to put that stress upon us just to conform to a versioning scheme.

YL
onli
Regular
Posts: 2822
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: Github branches - Commit policy

Post by onli »

garvinhicking wrote:You are right though, we mixed up "fixing a bug" and "pushing new features to the users".
That is exactly my point :)
Which wouldn't even be bad if everything went perfect, but the unintended consequences of that new feature is the perfect example why we shouldn't do this.

I would try to push such a change only to master, not to 2.0. Then it can be tested there for a while longer, even if we need a fast bugfix release like with 2.0.1. And a 2.1 doesn't have to be too far away.

Though to be fair, that specific bug we probably would never have found.
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: Github branches - Commit policy

Post by Timbalu »

Garvins origin idea of 'style_user.css' was IMHO better, since that would not have had "broken" other instances.
We now have the culprit, beside the {TEMPLATE_PATH} thing and the manual deactivation thing, that copy templates might still include a theme user.css, since that change wasn't announced to clear up by user in the upgrader notifications.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: Github branches - Commit policy

Post by garvinhicking »

Timbalu wrote:Garvins origin idea of 'style_user.css' was IMHO better, since that would not have had "broken" other instances.
Nah, not really - then users would have needed to migrate their user.css contents to that new file.

I think the TEMPLATE_PATH thing is not soo important, if people use it, they can adjust it in the user.css (they could even use the full absolute path and not use a smarty placeholder, most people will get that intuitively I think)...

But yes, I now see this wasn't such a good idea to port to 2.0.x.
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: Github branches - Commit policy

Post by Timbalu »

No excuses. I didn't want to ride this horse! :)
I just wanted to note this in that regard/context.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: Github branches - Commit policy

Post by yellowled »

For the record: I actually like that {$TEMPLATE_PATH} now works in the user.css as well.

YL
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: Github branches - Commit policy

Post by Timbalu »

yellowled wrote:For the record: I actually like that {$TEMPLATE_PATH} now works in the user.css as well.
No. It does not. Though {TEMPLATE_PATH} does! :) (It's a "regex like" string replacement, not a variable.)
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Post Reply