Hi,
On Sun, Nov 07, 2010 at 03:23:35PM +0100, Reinier Lamers wrote:
[2.4 and 2.5 pain snipped]
> Such issues delaying the release are a real problem. The longer a release
> branch is separated, the harder it will be to merge fixes from HEAD into the
> release branch and to merge the tags from the release branch back into HEAD.
Why use a release branch at all, *before* the release happens? It
may sound strange, but I'm serious. [Note that what I'm suggesting
here and below is backed on how the OpenBSD release process is done;
it may or may not work for darcs; it depends on the size of the
project (darcs is much smaller than a whole operating system) but
also on the amount of developers and users willing to test stuff
(probably also smaller then for OpenBSD). And please note that I'm
*not* a darcs developer, although I'm at least testing darcs-HEAD
from time to time]
> Also, I am afraid that pushing out release candidates with 2 or 3 weeks
> between them with very little changes does not make us look like a vibrant
> project.
Letting `release candidates' happen based on HEAD (and asking people
to use daily source snapshots or just the sources from the repository)
would fix this.
If there's a window of some days (or even two or three weeks) where
only release-critical patches are allowed to be pushed to the
repository, you're in a very comfortable position (bug found, bug
gets fixed, people can re-test -- no need for any merging work, and
no need to publish another release candidate, as you can just point
the bug reporter(s) to the next daily snapshot or to pull from the
repo).
> We hope to address the problem of lots of regressions being found by doing
> alpha releases whenever big changes are merged into HEAD. But the problem of
> release-critical bugs not being picked up remains.
Big changes should stop some time before the late release cycle
happens. This should be announced, so people who are not involved
in the development (and not running HEAD all the time) have a chance
to give HEAD a try, if they're brave enough.
Of course this may fail, in case only developers are running HEAD
on a daily base. If this happens, it means that there are too few
developers (or/and people running HEAD). Which in turn means that
there are too many big changes causing regressions which scares
people to test HEAD frequently.
> I think we have to change our approach to releases to make future releases go
> more smoothly. The idea that the release manager just takes the current state
> of HEAD, fixes a couple of small bugs reported by beta users and announces a
> stable release doesn't work. We have to commit to a release as a team.
Which can be enforced by not using a release branch in the first
place. Developers *should* eat their own dogfood. Users who rely
on darcs and who have the time (and ability) to test HEAD on a
regular schedule should do this, too.
> That means that when we are in a release cycle, the release should be the
> most
> important darcs issue for all developers. When a release-critical regression
> is discovered, it should be picked up in a couple of days, not weeks. If a
> regression is discovered that was introduced by your code, it's time to drop
> other darcs things you are working on and fix it right away.
That would mean that changes causing regressions would just be
rolled back from HEAD and could worked on again after the actual
release happened.
> The problem with such an approach is that we are all volunteers. There is no
> way a Release Manager can order you to work on something or to work at all.
No, but if there are issues (either regressions or new bugs) that
can be tracked down to a single patch (or a small set of patches),
you can ask the authors to either fix it within a few days or just
rollback the patches. If this affects several other patches depending
on those bad patches -- bad look. But it may be better to rollback
even good stuff (which depends on bad stuff) and restart from scratch
than trying to fix the bad stuff without breaking the godd stuff
depending on it. At least when you're in release-mode (i.e. a small
time window of a few weeks).
> Still, perhaps we can increase people's commitment to releases by making them
> more feature-based than they are now.
>
> So instead of saying that we release darcs 2.X at time Y with whatever
> features are ready by then, we make a realistic list of features that should
> be in a new darcs release well in advance[*]. We could make a list of
> features
> for the next release immediately after every minor release. I hope that if we
> have a concrete idea of what the next darcs release will look like, we will
> be
> more focused to deliver it.
That won't work. Planning ahead which features will make it into
the next release can't work. It doesn't work for commercial projects
(small or large ones), and it just can't work for volunteer projects
like darcs.
Suppose you're at darcs-4.2, and are planning a release for darcs-4.3
a few months later, with some super-cool features added. What if
those features additions just aren't finished until the release
time for darcs-4.3?
On the other hand, if you just do releases based on HEAD (which
some slowed-done development process happening a few weeks before
the release), you'll get what got done. It may be new features, but
it may also be just some bug fixes or performance improvements. But
you don't have to worry much about the quality on the release, and
you don't have to defer the release.
> Now I realize that these ideas conflict with the current darcs culture, and I
> also realize that it remains to be seen if I can practice what I preach next
> to my day job. Still I'm interested in hearing your opinions.
But what *is* the current darcs culture? That's a honest question,
because I'm a slacker and not following all the discussions here
and all pushed patches, especially if it comes to when and how new
features are added and when and how bugs are fixed.
I don't know whether a HEAD-based release process would work for darcs,
and huge changes would be more difficult to get in (becase they'd be
done in small steps), but maybe it's worth a try, anyway.
Just my 2p
Kili
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
