[haiku-development] Re: Haiku R1A5 release timeline
- From: Augustin Cavalier <waddlesplash@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 2 Jun 2014 18:30:53 -0400
On Jun 2, 2014 5:47 PM, "PulkoMandy" <pulkomandy@xxxxxxxxx> wrote:
> To make things clear, I am willing to be the release coordinator for
> alpha5. The short timeline set up by Kallisti5 and my vacations during
> last week made this difficult, but now that I'm back from vacations, I
> can handle this fine.
Oh, OK -- I was all set up and had already started planning on doing it
(actually I may be able to do it full time over the summer as volunteer
work, and I already sent this to the mailing list a few times) but I
suppose you're more qualified...
I had started preliminary planning for an August release, if you want to go
with that.
> This morning I filtered the trac ticket and moved away things that
> shouldn't delay alpha5 from the milestone. This doesn't mean these
> issues won't be fixed for alpha5, if someone does the work, it can be
> integrated into the release. However, if we keep adding stuff to the
> next release, it will simply never happen.
Most of those I assigned to myself, and yes, if I'm doing it full-time I
will get to it.
> Following this, there are things that are out of scope:
> - ffmpeg update
GCC4 completed.
> - Qt update
Already competed, just needs packaging.
> - USB3 support
Probably not happening since Jerome is busy.
> - several hardware specific issues that can be worked around by
> blacklisting drivers
> I have moved matching tickets out of the alpha5 milestone.
Some I approve of, some in don't. But since I appear to have been replaced,
it's your call.
> Several issues were raised on this ML thread. I'll create issues for
> them if no one does. This includes:
> * The haikuports repo is in inconsistent state, so we can't build a
> full set of packages
> * The upgrade path for alpha5 should be defined (do we want to have a
> separate repo for it? should all packages require haiku "alpha5"
> instead of a specific hrev?)
>
> Once these issues (and probably I missed some more) are solved, we can
> see how far we are and setup a timeline.
>
> On the release process, I would like to lock commit access to the
> trunk, and have all changes go through review on gerrit before they
> are merged. This would allow for a simpler workflow than what we used
> for previous releases, and could be made permanent to keep the trunk
> in "releasable" state at all times. However, we don't have Gerrit
> running yet, so if needed we will go with the traditional branch+merge
> way once more. In that case, we need the branch to be more
> short-lived, so it would be better to solve the major issues before
> creating it.
+1.
-Augustin
Other related posts:
