Re: [Wikitech-l] INFO: Reading web release process update

[Joaquin Oltra Hernandez]

On Wed, Jan 27, 2016 at 6:27 PM, Greg Grossmeier  wrote:

> 
> > Feature flagging or using feature branches for certain things may be a
> way
> > to go for certain things, we're keeping that in mind definitely, thanks
> for
> > the reminder Greg.
>
> Just be clear: feature branches aren't feature flags and take you back
> to a place closer to a 'dev' branch :).
>
>
Sure! I was just pointing out two other options that could be considered
depending on tradeoffs.


> > I agree with you regarding releases Gergo. The good thing about the
> > *release*s was mainly the curated changelog of changes for that release.
> A
> > proposal I like is do the changelog every week with the train before the
> > release branch is done. We'll need to establish owners for being
> effective
> > at doing that.
>
> It looks like the release notes[0] are just git short logs, yes? Or is
> the HISTORY file not what you are referring to (I only did a quick
> look)?
>
> If it is just the git shortlog, take a look here:
> eg: https://www.mediawiki.org/wiki/MediaWiki_1.27/wmf.11#MobileFrontend
>
> Those pages are automatically created and posted every week with the
> train, for free (by RelEng).
>

Nice, we were doing a filtered git log
 so
that's going to work just fine.

Thanks for the help Greg.


> Greg
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] INFO: Reading web release process update

[Greg Grossmeier]

> Feature flagging or using feature branches for certain things may be a way
> to go for certain things, we're keeping that in mind definitely, thanks for
> the reminder Greg.

Just be clear: feature branches aren't feature flags and take you back
to a place closer to a 'dev' branch :).

> I agree with you regarding releases Gergo. The good thing about the
> *release*s was mainly the curated changelog of changes for that release. A
> proposal I like is do the changelog every week with the train before the
> release branch is done. We'll need to establish owners for being effective
> at doing that.

It looks like the release notes[0] are just git short logs, yes? Or is
the HISTORY file not what you are referring to (I only did a quick
look)?

If it is just the git shortlog, take a look here:
eg: https://www.mediawiki.org/wiki/MediaWiki_1.27/wmf.11#MobileFrontend

Those pages are automatically created and posted every week with the
train, for free (by RelEng).

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] INFO: Reading web release process update

[Joaquin Oltra Hernandez]

Feature flagging or using feature branches for certain things may be a way
to go for certain things, we're keeping that in mind definitely, thanks for
the reminder Greg.

I agree with you regarding releases Gergo. The good thing about the
*release*s was mainly the curated changelog of changes for that release. A
proposal I like is do the changelog every week with the train before the
release branch is done. We'll need to establish owners for being effective
at doing that.

On Wed, Jan 27, 2016 at 12:43 AM, Gergo Tisza  wrote:

> On Tue, Jan 26, 2016 at 2:11 PM, Jon Robson  wrote:
>
> > We think this will be a better approach for everyone. Our only remaining
> > question is when and if to do release number bumps in future. We'll be
> back
> > with an answer about that shortly... ideas welcomed.
> >
>
> Who is the target audience of release numbers? If it is third-party wikis,
> they will probably only care about release branches (REL1_26 etc) and you
> don't have to do anything about that (except backporting fixes for
> especially nasty bugs), extension branches get split automatically whenever
> there is a new MediaWiki release.
>
> On the topic of +2 vs. accepting tasks in Scrum, synchronizing the scrum
> schedule with the release process (so that sprints start on Tuesday and end
> on Monday) reduces the pain. Although if you use two-week sprints that's
> probably less useful.
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] INFO: Reading web release process update

[Gergo Tisza]

On Tue, Jan 26, 2016 at 2:11 PM, Jon Robson  wrote:

> We think this will be a better approach for everyone. Our only remaining
> question is when and if to do release number bumps in future. We'll be back
> with an answer about that shortly... ideas welcomed.
>

Who is the target audience of release numbers? If it is third-party wikis,
they will probably only care about release branches (REL1_26 etc) and you
don't have to do anything about that (except backporting fixes for
especially nasty bugs), extension branches get split automatically whenever
there is a new MediaWiki release.

On the topic of +2 vs. accepting tasks in Scrum, synchronizing the scrum
schedule with the release process (so that sprints start on Tuesday and end
on Monday) reduces the pain. Although if you use two-week sprints that's
probably less useful.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] INFO: Reading web release process update

[Greg Grossmeier]

Thanks for this writeup (and the wiki page), Jon. Much appreciated.

I only have one question/thought:


> When we work on new features, we will be more mindful of +2, marking the
> initial commit of a chain of commits that requires sign off from a designer
> and product owner with a -2.

Wouldn't feature flagging[0], broadly termed, help here?

Other than that, I think you all made the right choice.

Greg


[0] Martin Fowler uses "feature toggle":
http://martinfowler.com/articles/feature-toggles.html is a good
overview.

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] INFO: Reading web release process update

[Jon Robson]

As you may be aware, the reading team was unhappy with its current release
process and shared its rationale

for a different release process. This resulted in an experiment on Gather,
QuickSurveys, Cards and RelatedArticles where the team developed on the dev
branch by default. When the team was happy that the dev branch was stable,
it would tag a release and merge to master. The idea was to minimise the
deployment of incomplete features and SWAT deploys.

This process saw mixed success. Although we felt more comfortable and in
control of the code we shipped due to more time for designers and product
owners to input into our process it was clear there was an impedance
mismatch with the expectations in the MediaWiki developer community and for
a small team of 5, we were unable to keep up with the periodic releases of
extensions we were not actively maintaining.

As a result we are abandoning this experiment and going back to
the Mediawiki Way™ of releasing and merging directly to master.

When we work on new features, we will be more mindful of +2, marking the
initial commit of a chain of commits that requires sign off from a designer
and product owner with a -2.

We think this will be a better approach for everyone. Our only remaining
question is when and if to do release number bumps in future. We'll be back
with an answer about that shortly... ideas welcomed.

Thank you for your patience while we experimented and let us know if there
is anything else of interest to you in this experiment we have run.

Notes from post-mortem are on wiki

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l