| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
Marius Mauch wrote: |
| 5 |
> On Thu, 06 Apr 2006 19:11:49 -0700 |
| 6 |
> Zac Medico <zmedico@g.o> wrote: |
| 7 |
> |
| 8 |
>> The manifest code doesn't have very many use cases so I'd expect that |
| 9 |
>> we would have hit most major problems by now (even with a small |
| 10 |
>> sample). Any necessary changes are likely to be small patches. As |
| 11 |
>> an alternative, we can cut the 2.1 branch at the point before |
| 12 |
>> manifest2 was merged (2.1_pre7, essentially). |
| 13 |
> |
| 14 |
> Releasing 2.1 without manifest2 is a no go, it would significantly |
| 15 |
> delay the deployment and transition.I'm not requesting to delay 2.1 |
| 16 |
> for another few months, just one more pre release so people get a |
| 17 |
> chance to test it for one or two weeks. |
| 18 |
|
| 19 |
Well, 2 weeks isn't so bad. I'm just annoyed by the length of this release cycle and would prefer shorter release cycles in the future. |
| 20 |
|
| 21 |
>>> The remaining feature I'd like to get into 2.1 is the |
| 22 |
>>> tree-format-check issue, but that could probably be slipped in in |
| 23 |
>>> the rc phase (don't really like that idea, but it's an option). |
| 24 |
>> I don't want to rush the development of new features such as |
| 25 |
>> manifest2 or the tree-format-check. We have a 2.1 branch that, in |
| 26 |
>> it's current state (2.1_pre7-r4, for example), provides significant |
| 27 |
>> benefits over the 2.0.x branch. By delaying 2.1's release for the |
| 28 |
>> addition of _new_ features, we run the risk of the release being |
| 29 |
>> delayed indefinitely by "just one more feature" syndrome. |
| 30 |
>> Personally, I'd rather have shorter release periods so that "just one |
| 31 |
>> more feature" syndrome becomes less of an issue. |
| 32 |
> |
| 33 |
> Ehm, this is not "just one more feature", both manifest2 and |
| 34 |
> the tree-format-check are things to improve forward compability (or for |
| 35 |
> the latter even enable forward compability at all), so delaying them |
| 36 |
> will hinder future development, not only for us. |
| 37 |
|
| 38 |
This kind of thing will be less of a problem if we shorten the period of the release cycle. If we shorted it to 2 months or so, then it won't matter much when something gets bumped to the next cycle. |
| 39 |
|
| 40 |
> Also this isn't exactly news to you all as I sent my intentions already |
| 41 |
> a while ago, and last I asked you all agreed with them, so is there any |
| 42 |
> reason to rush this now? |
| 43 |
|
| 44 |
Like I've said above, I'm annoyed by the length of this release cycle. The gap between 2.0.x and 2.1 has grown so large that a 2.0.55 release seems (in my mind) like beating a dead horse. The way I see it, a shorter release cycle is needed so that bug fixes are released in _stable_ versions sooner. |
| 45 |
|
| 46 |
Zac |
| 47 |
-----BEGIN PGP SIGNATURE----- |
| 48 |
Version: GnuPG v1.4.2.2 (GNU/Linux) |
| 49 |
|
| 50 |
iD8DBQFENgiD/ejvha5XGaMRAu2qAKDst/u+JAPsKzthJp519I/01h3/WwCeO3RP |
| 51 |
jxoDVyn0MeeeMY+6qxq7QQY= |
| 52 |
=CdiB |
| 53 |
-----END PGP SIGNATURE----- |
| 54 |
-- |
| 55 |
gentoo-portage-dev@g.o mailing list |
Archives