Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18)

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


innocentkiller at gmail

Apr 29, 2011, 6:05 PM

Post #1 of 16 (1165 views)
Permalink
Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18)

On Wed, Apr 27, 2011 at 12:43 PM, Chad <innocentkiller [at] gmail> wrote:
> Getting the merges reviewed [0] and making sure we have a good set of
> release notes. That's what I know of, and Reedy's been working on the
> latter.
>

I've been thinking about this over the past few days, and I've got a proposed
release schedule and development roadmap to carry us through the rest of the
year.

As we all know, 1.17 is due to drop Real Soon Now. To summarize for those who
don't know the status: it's pretty much done. In talking with Roan, Tim and Sam
earlier this week, we discussed that we're pretty much ready to drop a
1.17beta1.
Tim was concerned about the release notes, but as I pointed out in my previous
e-mail, Sam's tidied this up (and it's low-hanging fruit if someone wants to
check behind us for sanity). That being said, I don't see any reason why we
can't drop a beta1 sometime this week. Give it a week, and drop a beta2. Wait
another week, then go final I think, all depending on what response we get from
the betas.

As for 1.18, I say we branch it the same day we drop 1.17 final (making the
branch is easy). There's still quite a bit of code to review, but going ahead
and giving ourselves a cutoff point will make catching up easier. Large projects
still outstanding in 1.18 to review are the img_metadata merge, and rewrites of
Skin and Action code. By branching soon I think we can try to get a release out
by the end of summer, at the very latest.

Looking ahead to 1.19, I'd like to do the same and branch soon after 1.18 has
been dropped. Since 1.19's a little further out and hasn't started taking shape
yet, I'd like to go ahead and propose what sort of release we should aim for.

Going back over the past couple of releases, we've had quite a few "rewrites"
of major portions of code. While these are a necessary part of the process of
developing MW, they are difficult to review due to their complexity. This
complexity also makes it more likely for things to break. If I may be so bold,
I would like to ask that 1.19 not contain any of these rewrites. Let's focus on
making it a bugfix/cleanup release. Personally I think it would make for a very
clean and polished release, as well as reducing the time for us to review and
ship it.

If we go this route, I don't see any reason we couldn't ship 1.19 by year end
(or if we really push, 11.11.11, as the other thread suggested). I
think it would
put us in a really good place to move forward into 2012, and help get us back
into a somewhat regular release pattern.

I really would love to hear from people to see if they think I'm crazy or if
this could work out fairly well. I know it's pretty tl;dr for most people, but
the ones who read it are the ones I wanna hear from anyway ;-)


-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jeroendedauw at gmail

Apr 29, 2011, 6:37 PM

Post #2 of 16 (1147 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18) [In reply to]

+1;

Sent from my Android phone.
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


maxsem.wiki at gmail

Apr 29, 2011, 10:41 PM

Post #3 of 16 (1148 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18) [In reply to]

On Sat, Apr 30, 2011 at 5:05 AM, Chad <innocentkiller [at] gmail> wrote:

>
> As for 1.18, I say we branch it the same day we drop 1.17 final (making the
> branch is easy). There's still quite a bit of code to review, but going
> ahead
> and giving ourselves a cutoff point will make catching up easier. Large
> projects
> still outstanding in 1.18 to review are the img_metadata merge, and
> rewrites of
> Skin and Action code. By branching soon I think we can try to get a release
> out
> by the end of summer, at the very latest.
>

Suggest waiting a couple of weeks in case a lot of bugs will be discovered
in 1.17 release, to reduce the number of needed merges.
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


roan.kattouw at gmail

Apr 30, 2011, 4:00 AM

Post #4 of 16 (1143 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18) [In reply to]

On Sat, Apr 30, 2011 at 3:05 AM, Chad <innocentkiller [at] gmail> wrote:
> Looking ahead to 1.19, I'd like to do the same and branch soon after 1.18 has
> been dropped. Since 1.19's a little further out and hasn't started taking shape
> yet, I'd like to go ahead and propose what sort of release we should aim for.
>
> Going back over the past couple of releases, we've had quite a few "rewrites"
> of major portions of code. While these are a necessary part of the process of
> developing MW, they are difficult to review due to their complexity. This
> complexity also makes it more likely for things to break. If I may be so bold,
> I would like to ask that 1.19 not contain any of these rewrites. Let's focus on
> making it a bugfix/cleanup release. Personally I think it would make for a very
> clean and polished release, as well as reducing the time for us to review and
> ship it.
>
I like this idea, although it does mean pushing back the
iwtransclusion branch merge to 1.20, presumably. But then you say:

> If we go this route, I don't see any reason we couldn't ship 1.19 by year end
> (or if we really push, 11.11.11, as the other thread suggested).
We'd be branching 1.18 in mid-May (when 1.17 goes final). If we
release a beta of 1.19 in November and it's a small release, we should
branch in October (or branch in November and release by year end).
That means there'd be 5 or 6 months of development in 1.19. I'm on
board with shooting for a clean and polished release, but we shouldn't
make /any/ release longer than 4 months, and this one should probably
be 3 IMO. Also, 6 months is a long time for a ban on rewrites.

I've seen a few suggestions about release schedules on this list now,
and all of them seem to, implicitly or explicitly, accept that
releases contain outrageous amounts of code and take more than 3
months to stabilize, just because that's what happened with 1.17.
Instead, I'd like us to be ambitious about not repeating the 1.17
fiasco, and aiming for a shorter cycle. Tim is right in the other
thread that cycles can be too short, but I think once every 3-4 months
is good middle ground. In any case, if stabilizing a release to even
get it to the first beta takes more than a month, something is
fundamentally wrong IMO.

> think it would
> put us in a really good place to move forward into 2012, and help get us back
> into a somewhat regular release pattern.
>
I agree and applaud this goal, though per the above I'm not entirely
sure we mean the same thing when we say "regular release pattern".

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


innocentkiller at gmail

Apr 30, 2011, 4:54 AM

Post #5 of 16 (1144 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18) [In reply to]

On Sat, Apr 30, 2011 at 7:00 AM, Roan Kattouw <roan.kattouw [at] gmail> wrote:
> I like this idea, although it does mean pushing back the
> iwtransclusion branch merge to 1.20, presumably. But then you say:
>

That thought occurred to me, it would require pushing iwtransclusion
back a bit.

>> If we go this route, I don't see any reason we couldn't ship 1.19 by year end
>> (or if we really push, 11.11.11, as the other thread suggested).
> We'd be branching 1.18 in mid-May (when 1.17 goes final). If we
> release a beta of 1.19 in November and it's a small release, we should
> branch in October (or branch in November and release by year end).
> That means there'd be 5 or 6 months of development in 1.19. I'm on
> board with shooting for a clean and polished release, but we shouldn't
> make /any/ release longer than 4 months, and this one should probably
> be 3 IMO. Also, 6 months is a long time for a ban on rewrites.
>
> I've seen a few suggestions about release schedules on this list now,
> and all of them seem to, implicitly or explicitly, accept that
> releases contain outrageous amounts of code and take more than 3
> months to stabilize, just because that's what happened with 1.17.
> Instead, I'd like us to be ambitious about not repeating the 1.17
> fiasco, and aiming for a shorter cycle. Tim is right in the other
> thread that cycles can be too short, but I think once every 3-4 months
> is good middle ground. In any case, if stabilizing a release to even
> get it to the first beta takes more than a month, something is
> fundamentally wrong IMO.
>

My math was bad :) I was mainly looking at how long it took us to
stabilize and release 1.17, and didn't really think we could get more
than 3 releases (1.17, 18 and 19) out by year end. I think anything
more ambitious than that is a little crazy on our part. But you're right,
6 months is a long time to say "don't rewrite stuff." That's why I asked
for feedback.

>> think it would
>> put us in a really good place to move forward into 2012, and help get us back
>> into a somewhat regular release pattern.
>>
> I agree and applaud this goal, though per the above I'm not entirely
> sure we mean the same thing when we say "regular release pattern".
>

Regular here being "more than 1 and a half releases a year" :p


-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


roan.kattouw at gmail

Apr 30, 2011, 5:09 AM

Post #6 of 16 (1142 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18) [In reply to]

On Sat, Apr 30, 2011 at 1:54 PM, Chad <innocentkiller [at] gmail> wrote:
> My math was bad :) I was mainly looking at how long it took us to
> stabilize and release 1.17
I just want to reiterate that 1.17 is not necessarily a good precedent
that's representative of 'normal' releases.

> , and didn't really think we could get more
> than 3 releases (1.17, 18 and 19) out by year end.
It's not entirely fair to attribute 1.17 to this year, since it was
branched last year. If we branch 1.18 when we release 1.17 and have a
sane release latency, we'll have two releases in two months, but
that's entirely due to wildly different latencies. The branch points
would be mostly regular though.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


happy-melon at live

Apr 30, 2011, 3:54 PM

Post #7 of 16 (1138 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of1.17 & 1.18) [In reply to]

"Chad" <innocentkiller [at] gmail> wrote in message
news:BANLkTi=mwb7GdCfZfTm4VxbwLn3iKStw+w [at] mail
> On Wed, Apr 27, 2011 at 12:43 PM, Chad <innocentkiller [at] gmail> wrote:
> Tim was concerned about the release notes, but as I pointed out in my
> previous
> e-mail, Sam's tidied this up (and it's low-hanging fruit if someone wants
> to
> check behind us for sanity). That being said, I don't see any reason why
> we
> can't drop a beta1 sometime this week. Give it a week, and drop a beta2.
> Wait
> another week, then go final I think, all depending on what response we get
> from
> the betas.

+1

> As for 1.18, I say we branch it the same day we drop 1.17 final (making
> the
> branch is easy).

+1. I think porting 1.17 fixes to 1.18 is a much lesser evil than allowing
the 1.18 branch to get any bigger.

> There's still quite a bit of code to review, but going ahead
> and giving ourselves a cutoff point will make catching up easier. Large
> projects
> still outstanding in 1.18 to review are the img_metadata merge, and
> rewrites of
> Skin and Action code.

The plan *was* to revert the Action rewrite from 1.18 and put it into 1.19.
If that's not going to happen then we should probably either a) push on with
its development and try and get it fully in place for 1.18, b) (my
preference) stabilise what's already there and leave it as a
partially-used-framework like Message, or c) revert it altogether. We can't
roll it back out of 1.18 *and* 1.19.

> Looking ahead to 1.19, I'd like to do the same and branch soon after 1.18
> has
> been dropped.

+1

> Going back over the past couple of releases, we've had quite a few
> "rewrites"
> of major portions of code. While these are a necessary part of the process
> of
> developing MW, they are difficult to review due to their complexity. This
> complexity also makes it more likely for things to break. If I may be so
> bold,
> I would like to ask that 1.19 not contain any of these rewrites. Let's
> focus on
> making it a bugfix/cleanup release. Personally I think it would make for a
> very
> clean and polished release, as well as reducing the time for us to review
> and
> ship it.

+0 -- I don't have time in the next six months to take the hedgecutters to
anything else in the codebase anyway... :-D

> If we go this route, I don't see any reason we couldn't ship 1.19 by year
> end
> (or if we really push, 11.11.11, as the other thread suggested). I
> think it would
> put us in a really good place to move forward into 2012, and help get us
> back
> into a somewhat regular release pattern.

If it helps with getting onto a regular release pattern, then that's good.
We need to be careful that that doesn't come at the expense of Useful Stuff
Not Getting Done: it would be very easy to maintain a release schedule if we
never added any new features, but it would be fairly pointless. I do
understand what you mean, and I think it would be a worthwhile exercise;
just as long as we treat it as an experiment.

> I really would love to hear from people to see if they think I'm crazy or
> if
> this could work out fairly well. I know it's pretty tl;dr for most people,
> but
> the ones who read it are the ones I wanna hear from anyway ;-)

I approve of this response-filtration scheme... :-D

--HM





_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


tstarling at wikimedia

May 1, 2011, 11:41 PM

Post #8 of 16 (1138 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18) [In reply to]

On 30/04/11 11:05, Chad wrote:
> On Wed, Apr 27, 2011 at 12:43 PM, Chad <innocentkiller [at] gmail> wrote:
>> Getting the merges reviewed [0] and making sure we have a good set of
>> release notes. That's what I know of, and Reedy's been working on the
>> latter.
>>
>
> I've been thinking about this over the past few days, and I've got a proposed
> release schedule and development roadmap to carry us through the rest of the
> year.
>
> As we all know, 1.17 is due to drop Real Soon Now. To summarize for those who
> don't know the status: it's pretty much done. In talking with Roan, Tim and Sam
> earlier this week, we discussed that we're pretty much ready to drop a
> 1.17beta1.

Maybe we can talk about this again tonight my time, if you're around.

> Tim was concerned about the release notes, but as I pointed out in my previous
> e-mail, Sam's tidied this up (and it's low-hanging fruit if someone wants to
> check behind us for sanity).

It would be nice if someone could write a user-oriented summary of the
major changes in the branch, like I did for 1.16. The 1.16 one was
used for the RELEASE-NOTES file, the mediawiki-announce email and the
blog post. The 1.17 one would probably be used in the same places.

> Looking ahead to 1.19, I'd like to do the same and branch soon after 1.18 has
> been dropped. Since 1.19's a little further out and hasn't started taking shape
> yet, I'd like to go ahead and propose what sort of release we should aim for.
>
> Going back over the past couple of releases, we've had quite a few "rewrites"
> of major portions of code. While these are a necessary part of the process of
> developing MW, they are difficult to review due to their complexity. This
> complexity also makes it more likely for things to break. If I may be so bold,
> I would like to ask that 1.19 not contain any of these rewrites. Let's focus on
> making it a bugfix/cleanup release. Personally I think it would make for a very
> clean and polished release, as well as reducing the time for us to review and
> ship it.

The usual situation is that some developers are interested in features
and others are interested in bug fixes. If you declare that you only
want bug fixes, you risk losing the feature developers.

I think that the best way to retain feature developers is to treat
them with respect and to value their contributions. That is why I
haven't proposed a "feature freeze" in the past.

It would be possible to do a stability-oriented release if that's
really what the community wants, but it would have to be carefully
managed. We would have to increase our mentoring and review activity
in the development branches, and keep the schedule very tight indeed.

Given our past record, I'm not really confident that we can pull that
off. There's a risk of screwing it up badly and offending a lot of
people. Release management isn't exactly an organisational strength.

-- Tim Starling


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


maxsem.wiki at gmail

May 2, 2011, 12:06 AM

Post #9 of 16 (1138 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18) [In reply to]

On 02.05.2011, 10:41 Tim wrote:

> It would be nice if someone could write a user-oriented summary of the
> major changes in the branch, like I did for 1.16. The 1.16 one was
> used for the RELEASE-NOTES file, the mediawiki-announce email and the
> blog post. The 1.17 one would probably be used in the same places.

I started that at http://www.mediawiki.org/wiki/MediaWiki_1.17 some
time ago, needs more collaboration.

--
Best regards,
Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


innocentkiller at gmail

May 2, 2011, 9:21 AM

Post #10 of 16 (1127 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18) [In reply to]

On Mon, May 2, 2011 at 2:41 AM, Tim Starling <tstarling [at] wikimedia> wrote:
>> Looking ahead to 1.19, I'd like to do the same and branch soon after 1.18 has
>> been dropped. Since 1.19's a little further out and hasn't started taking shape
>> yet, I'd like to go ahead and propose what sort of release we should aim for.
>>
>> Going back over the past couple of releases, we've had quite a few "rewrites"
>> of major portions of code. While these are a necessary part of the process of
>> developing MW, they are difficult to review due to their complexity. This
>> complexity also makes it more likely for things to break. If I may be so bold,
>> I would like to ask that 1.19 not contain any of these rewrites. Let's focus on
>> making it a bugfix/cleanup release. Personally I think it would make for a very
>> clean and polished release, as well as reducing the time for us to review and
>> ship it.
>
> The usual situation is that some developers are interested in features
> and others are interested in bug fixes. If you declare that you only
> want bug fixes, you risk losing the feature developers.
>
> I think that the best way to retain feature developers is to treat
> them with respect and to value their contributions. That is why I
> haven't proposed a "feature freeze" in the past.
>

I understand, respect, and value the contributions of people who want to
add new features. Features are what moves the product forward, and at
no point do we want to be hostile to people willing to put in their time and
effort to add functionality.

Given that our patch review process isn't fantastic, I really don't think it
would affect the majority of bugs anyway. Mainly affected would be
people with core access who write a new feature without putting it
through BZ first. Given that our core group is relatively small, I figured
we could come to some sort of consensus, if we do indeed move forward
with this.

> It would be possible to do a stability-oriented release if that's
> really what the community wants, but it would have to be carefully
> managed. We would have to increase our mentoring and review activity
> in the development branches, and keep the schedule very tight indeed.
>

I don't know what our development community wants. I just happened to
think it was a good idea and so brought it up for discussion. If we
collectively decide I'm nuts, we can toss this proposal, I won't be upset.
I know we'd need to keep development on a very strict timeframe, which
is why I outlined a more strict branching and timeline to stick to. As Roan
and others pointed out, 6 months is a little long. I don't think we couldn't
decide on a branch point and stick to it, especially if we're not holding up
a branch for someone to finish sorting out a rewrite or major feature they
didn't quite resolve.

> Given our past record, I'm not really confident that we can pull that
> off. There's a risk of screwing it up badly and offending a lot of
> people. Release management isn't exactly an organisational strength.
>

I agree it's not our strength, but I don't think we can't do it. I
think sticking
to a firm branch date would largely alleviate this issue. I remain convinced
that a stability-focused release would be a good idea at some point, whether
we do it now or in a year.

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


innocentkiller at gmail

May 2, 2011, 9:23 AM

Post #11 of 16 (1130 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18) [In reply to]

On Mon, May 2, 2011 at 3:06 AM, Max Semenik <maxsem.wiki [at] gmail> wrote:
> On 02.05.2011, 10:41 Tim wrote:
>
>> It would be nice if someone could write a user-oriented summary of the
>> major changes in the branch, like I did for 1.16. The 1.16 one was
>> used for the RELEASE-NOTES file, the mediawiki-announce email and the
>> blog post. The 1.17 one would probably be used in the same places.
>
> I  started  that  at http://www.mediawiki.org/wiki/MediaWiki_1.17 some
> time ago, needs more collaboration.
>

Thank you for starting this. Sam and I are poking at it now.

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


hashar+wmf at free

May 2, 2011, 11:14 AM

Post #12 of 16 (1131 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18) [In reply to]

On 02/05/11 09:06, Max Semenik wrote:
> I started that athttp://www.mediawiki.org/wiki/MediaWiki_1.17 some
> time ago, needs more collaboration.

And I started the 1.18 one with illustrative (and free) pictures :p

http://www.mediawiki.org/wiki/MediaWiki_1.18

--
Ashar Voultoiz


_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


happy-melon at live

May 2, 2011, 4:52 PM

Post #13 of 16 (1133 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18) [In reply to]

"Chad" <innocentkiller [at] gmail> wrote in message
news:BANLkTikd4Eb-V8W-kA1qe+=bnJxMJ+OxUA [at] mail
>
> I understand, respect, and value the contributions of people who want to
> add new features. Features are what moves the product forward, and at
> no point do we want to be hostile to people willing to put in their time
> and
> effort to add functionality.
>
> Given that our patch review process isn't fantastic, I really don't think
> it
> would affect the majority of bugs anyway. Mainly affected would be
> people with core access who write a new feature without putting it
> through BZ first. Given that our core group is relatively small, I figured
> we could come to some sort of consensus, if we do indeed move forward
> with this.
>
> ...
>
> I don't know what our development community wants. I just happened to
> think it was a good idea and so brought it up for discussion. If we
> collectively decide I'm nuts, we can toss this proposal, I won't be upset.
> I know we'd need to keep development on a very strict timeframe, which
> is why I outlined a more strict branching and timeline to stick to. As
> Roan
> and others pointed out, 6 months is a little long. I don't think we
> couldn't
> decide on a branch point and stick to it, especially if we're not holding
> up
> a branch for someone to finish sorting out a rewrite or major feature they
> didn't quite resolve.
>
>> Given our past record, I'm not really confident that we can pull that
>> off. There's a risk of screwing it up badly and offending a lot of
>> people. Release management isn't exactly an organisational strength.
>>
>
> I agree it's not our strength, but I don't think we can't do it. I
> think sticking
> to a firm branch date would largely alleviate this issue. I remain
> convinced
> that a stability-focused release would be a good idea at some point,
> whether
> we do it now or in a year.

Feature freezes don't have much potential in the current development climate
because the choice is basically between committing a feature to trunk and
not committing a feature at all. Development work done in branches might as
well be left in a working copy for all the attention it gets, BZ patches
doubly so. What would almost certainly happen in a feature freeze would be
that developers who are interested in core rewrites / major features would
simply queue up their work for the next release, which would make 1.20
another massively-rewritten monster. That, if not properly managed, is just
creating a bigger problem down the line; although conversely you could say
it would make for a particularly Awesome(TM) milestone release.

If a feature freeze is to work, it has to either a) be for a very short
period so that developers neither get disenchanted and wander off nor start
stockpiling working-copy changes to empty onto trunk once it's thawed, or b)
be part of a fundamental change in the way we approach rewrites. It would
be perfectly acceptable to move to a completely different paradigm where
branches are used properly, regularly reviewed, get plenty of
inter-developer testing and can be smoothly merged back into trunk in an
organised fashion. But right now, the only way to reliably get external
eyes on code is to put it in trunk; the occasions when multiple developers
are working on the same branch are both rare and not quite the same thing.

My login rewrite was done as a branch merge and was reverted three times
from 1.16 (not unreasonably, for sure, but for bugs flagged up by precisely
the sort of diverse testing that being in trunk provides and being in a
branch doesn't); it's now 30,000 revisions bitrotted and will probably have
to be redone from scratch. The 1.18 blocking rewrite was done in pieces in
trunk and looks to have settled in reasonably well. A feature freeze will
probably result in rather more of those Big Scary Commits (TM) -- either
branch merges or whole features put together in a working copy -- and fewer
features implemented through incremental changes. If we don't have
provisions in place to handle that in some way, it will probably create more
problems than it solves.

--HM







_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


innocentkiller at gmail

May 2, 2011, 5:49 PM

Post #14 of 16 (1131 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18) [In reply to]

On Mon, May 2, 2011 at 7:52 PM, Happy-melon <happy-melon [at] live> wrote:
> If a feature freeze is to work, it has to either a) be for a very short
> period so that developers neither get disenchanted and wander off nor start
> stockpiling working-copy changes to empty onto trunk once it's thawed, or b)
> be part of a fundamental change in the way we approach rewrites.  It would
> be perfectly acceptable to move to a completely different paradigm where
> branches are used properly, regularly reviewed, get plenty of
> inter-developer testing and can be smoothly merged back into trunk in an
> organised fashion.  But right now, the only way to reliably get external
> eyes on code is to put it in trunk; the occasions when multiple developers
> are working on the same branch are both rare and not quite the same thing.
>

I'm proposing (a). Shifting to (b) is an organizational shift, and some
people don't seem to think it can happen unless we move to the
Magical World of Git.

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Platonides at gmail

May 3, 2011, 12:20 PM

Post #15 of 16 (1130 views)
Permalink
Re: Release schedule for the rest of 2011 (was: Status of 1.17 & 1.18) [In reply to]

I find fine planning to have a "normal", small release. But if the code
development lead to eg. a parser rewrite, that's fine too. It can get
in, or reverted for the branch if too close to the brach point.
As far as it gets reviewed in time, it shouldn't be a problem. (We are
going to get everything timely reviewed™ this time, right? ;) However,
if it gets unreviewed three months, with furhter changes dependant of
it, and is only looked at two weeks before the branching date (and
obviously finding issues), then such rewrite becomes a big problem.



_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


mhershberger at wikimedia

May 3, 2011, 1:34 PM

Post #16 of 16 (1131 views)
Permalink
Re: Release schedule for the rest of 2011 [In reply to]

"Happy-melon" <happy-melon [at] live> writes:

> Development work done in branches might as well be left in a working
> copy for all the attention it gets

I'm not about to say that development branches get the love and
attention of trunk — just look at the mess we have with with
iwtransclusion branch. Here we are about 9 months later and the GSOC
code is just now being merged. (https://bugzilla.wikimedia.org/28673)

We are learning from that mistake, though. I think Sumanah is directing
current GSOC students to work on trunk instead of a branch.

> BZ patches doubly so.

I'm watching the front of the bug stream and, usually, when someone
finds bug and provides a patch, I apply it right away. If someone does
that enough (/me waves at Paul Copperman) then we try to get them commit
access.

Of course, things aren't perfect, but hopefully they are getting better.

Mark.

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.