Re: [Fwd: Re: [gentoo-portage-dev] 2.1 release candidate soon?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: > Vapier in particular has backported some changes into the 2.0.54 tree > with I assume hopes to make a 2.0.55 release. The 2.1 release is a > large change over the 2.0 series, I'd like to give people a bit more > time on 2.0. For a while this may mean 2.0 and 2.1 stable at the same > time, although there is no harm in that either. We haven't had a new > 2.0 release in a while, and there are features worth backporting IMHO. > > Remember that while most of the development community runs portage-2.1 > many of the users do not; and they have not seen a 2.0 release in some > time. I think we can stable 2.0.55 faster than 2.1, as 2.1 will > probably need a series of _rc releases before being considered stable. Maybe 2.0.55 can be stabled slightly faster. But is it really worth anyones time, even to keyword it? Not it my mind. As the gap widens between 2.0.54 and 2.1, the value of a 2.0.55 release diminishes accordingly. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENgwq/ejvha5XGaMRApvTAKDDr2QLizhvrgouTcf8UBidfnhsvQCgvWKC XFW64BXfCDTw2aPe2usj2eE= =N5au -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: > On Thu, 06 Apr 2006 19:11:49 -0700 > Zac Medico <[EMAIL PROTECTED]> wrote: > >> The manifest code doesn't have very many use cases so I'd expect that >> we would have hit most major problems by now (even with a small >> sample). Any necessary changes are likely to be small patches. As >> an alternative, we can cut the 2.1 branch at the point before >> manifest2 was merged (2.1_pre7, essentially). > > Releasing 2.1 without manifest2 is a no go, it would significantly > delay the deployment and transition.I'm not requesting to delay 2.1 > for another few months, just one more pre release so people get a > chance to test it for one or two weeks. 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. >>> The remaining feature I'd like to get into 2.1 is the >>> tree-format-check issue, but that could probably be slipped in in >>> the rc phase (don't really like that idea, but it's an option). >> I don't want to rush the development of new features such as >> manifest2 or the tree-format-check. We have a 2.1 branch that, in >> it's current state (2.1_pre7-r4, for example), provides significant >> benefits over the 2.0.x branch. By delaying 2.1's release for the >> addition of _new_ features, we run the risk of the release being >> delayed indefinitely by "just one more feature" syndrome. >> Personally, I'd rather have shorter release periods so that "just one >> more feature" syndrome becomes less of an issue. > > Ehm, this is not "just one more feature", both manifest2 and > the tree-format-check are things to improve forward compability (or for > the latter even enable forward compability at all), so delaying them > will hinder future development, not only for us. 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. > Also this isn't exactly news to you all as I sent my intentions already > a while ago, and last I asked you all agreed with them, so is there any > reason to rush this now? 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. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENgiD/ejvha5XGaMRAu2qAKDst/u+JAPsKzthJp519I/01h3/WwCeO3RP jxoDVyn0MeeeMY+6qxq7QQY= =CdiB -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
[Fwd: Re: [gentoo-portage-dev] 2.1 release candidate soon?]
Sorry, send with wrong address earlier. Original Message Subject: Re: [gentoo-portage-dev] 2.1 release candidate soon? Date: Thu, 06 Apr 2006 20:09:06 -0400 From: Alec Warner <[EMAIL PROTECTED]> To: gentoo-portage-dev@lists.gentoo.org References: <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Hi everyone, > > I think the current quality level of the 2.1 branch is good enough to > make it a release candidate. From my perspective, it seems like a > waste of everyone's time to roll a 2.0.55 release when 2.1 is a > perfectly good replacement (with lots of bug fixes relative to > 2.0.54). (Pardon if this looks weird, Thunderbird is doing all kinds of weird things to this E-mail) Vapier in particular has backported some changes into the 2.0.54 tree with I assume hopes to make a 2.0.55 release. The 2.1 release is a large change over the 2.0 series, I'd like to give people a bit more time on 2.0. For a while this may mean 2.0 and 2.1 stable at the same time, although there is no harm in that either. We haven't had a new 2.0 release in a while, and there are features worth backporting IMHO. Remember that while most of the development community runs portage-2.1 many of the users do not; and they have not seen a 2.0 release in some time. I think we can stable 2.0.55 faster than 2.1, as 2.1 will probably need a series of _rc releases before being considered stable. -Alec Warner (antarus) -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On 4/6/06, Marius Mauch <[EMAIL PROTECTED]> wrote:
> On Thu, 06 Apr 2006 19:11:49 -0700
> Zac Medico <[EMAIL PROTECTED]> wrote:
> > The manifest code doesn't have very many use cases so I'd expect that
> > we would have hit most major problems by now (even with a small
> > sample). Any necessary changes are likely to be small patches. As
> > an alternative, we can cut the 2.1 branch at the point before
> > manifest2 was merged (2.1_pre7, essentially).
>
> Releasing 2.1 without manifest2 is a no go, it would significantly
> delay the deployment and transition. I'm not requesting to delay 2.1
> for another few months, just one more pre release so people get a
> chance to test it for one or two weeks.
The manifest2 code is still pretty raw from where I'm sitting and has
a few design problems.
Offhand,
1) usage of settings sucks (awareness of PORTAGE_ACTUAL_DISTDIR is an
indication right there that distdir should be passed in rather then
manifest code knowing of settings). Throwing around a big ole dict of
settings while easy, isn't exactly encapsulated/seperated all that
well (thus making any changes to config class that much more of a
mess).
2) triggering __init__ within create is pretty dodgy and definitely a
"wtf" trick
3) usual loading everything into memory rather then iterating over
objects (file objects in particular)
4) incomplete class; notably the sign chunks.
5) lack of protection in digest parsing; flipping through it, any
old/deviate from the norm digest's generated (say files//blah) the
code doesn't protect itself against.
6) impenetrable code.
This should be simple/easily grokable code- as is, I don't think it is.
fex.
cpvlist = [os.path.join(self.pkgdir.rstrip(os.sep).split(os.sep)[-2],
x[:-7]) for x in \
portage.listdir(self.pkgdir) if x.endswith(".ebuild")]
I'm not in front of a gentoo box right now, and the best I can figure
that code is doing is pulling the ebuild name and joining the ebuild
name + version to it- and I'm pretty sure that's not a correct
interpretation of it.
The code should be _readable_ by folks, fhashdict (fex) should have an
explanation in __init__ explaining it's structure. Else folks are
stuck popping open the interpretter, and inspecting the object to
figure out what the code sets it to- which sucks because if you have
to inspect the implementation to determine it's intentions, finding
bugs in the implementation is that much harder.
Realistially, tend to think the code would be cleaner/more readable if
split into manifest1 and manifest2 classes. Combine then via a
derivative class instead of making manifest2 code (which will live on)
nastier to read.
Aside from that, my usual rant about creating uneccessary lists, using
.keys() when should just be iterating over the dict all apply for this
code, in general efficient code (usually resulting in less lines)
applies.
Honestly? Main issue I have with the code is that while the previous
digest/manifest code was icky, it was at least known to be stable via
live testing/usage by users/devs (for better or worse). The new code,
while containing most functionality in one spot is roughly just as
dense/opaque in trying to eyeball, but it lacks a year+ of being in
actual testing. That combination right there makes it harder to view
as "good to go".
/me notes also that he applies same criteria to what he has in the
past tried to push into portage; beyond features/bug fixes, whats the
cost in terms of maintenance? Will someone else be able to actually
grok this code without having to use pdb or liter it with print
statements?
Not intending to be an ass about the code, just think it needs to be
simpler then it is. Effectively it's just marshalling code (yes it
triggers chksum calls, but that's minor); it's not that complex of a
thing and the implementation should reflect that (or at least be
heavily documented if not).
> > > The remaining feature I'd like to get into 2.1 is the
> > > tree-format-check issue, but that could probably be slipped in in
> > > the rc phase (don't really like that idea, but it's an option).
> >
> > I don't want to rush the development of new features such as
> > manifest2 or the tree-format-check. We have a 2.1 branch that, in
> > it's current state (2.1_pre7-r4, for example), provides significant
> > benefits over the 2.0.x branch. By delaying 2.1's release for the
> > addition of _new_ features, we run the risk of the release being
> > delayed indefinitely by "just one more feature" syndrome.
> > Personally, I'd rather have shorter release periods so that "just one
> > more feature" syndrome becomes less of an issue.
>
> Ehm, this is not "just one more feature", both manifest2 and
> the tree-format-check are things to improve forward compability (or for
> the latter even enable forward compability at all), so delaying them
> will hinder future development, not only for us.
> Also this isn't exactly news to you all as I sent my intentions already
> a while ago, and last I asked you a
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Thu, 06 Apr 2006 19:11:49 -0700 Zac Medico <[EMAIL PROTECTED]> wrote: > The manifest code doesn't have very many use cases so I'd expect that > we would have hit most major problems by now (even with a small > sample). Any necessary changes are likely to be small patches. As > an alternative, we can cut the 2.1 branch at the point before > manifest2 was merged (2.1_pre7, essentially). Releasing 2.1 without manifest2 is a no go, it would significantly delay the deployment and transition. I'm not requesting to delay 2.1 for another few months, just one more pre release so people get a chance to test it for one or two weeks. > > The remaining feature I'd like to get into 2.1 is the > > tree-format-check issue, but that could probably be slipped in in > > the rc phase (don't really like that idea, but it's an option). > > I don't want to rush the development of new features such as > manifest2 or the tree-format-check. We have a 2.1 branch that, in > it's current state (2.1_pre7-r4, for example), provides significant > benefits over the 2.0.x branch. By delaying 2.1's release for the > addition of _new_ features, we run the risk of the release being > delayed indefinitely by "just one more feature" syndrome. > Personally, I'd rather have shorter release periods so that "just one > more feature" syndrome becomes less of an issue. Ehm, this is not "just one more feature", both manifest2 and the tree-format-check are things to improve forward compability (or for the latter even enable forward compability at all), so delaying them will hinder future development, not only for us. Also this isn't exactly news to you all as I sent my intentions already a while ago, and last I asked you all agreed with them, so is there any reason to rush this now? Marius -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: > On Thu, 06 Apr 2006 13:13:34 -0700 > Zac Medico <[EMAIL PROTECTED]> wrote: > >> So, I'd like to create 2.1 branch that is closed to mostly anything >> except regression fixes and release it as portage-2.1_rc1 this >> Saturday. We can continue to do ~arch releases of the development >> branch (2.2 or whatever it becomes) every 2 weeks. Does now seem >> like a good time for this transition? Your feedback would be >> appreciated. > > I'd like to hold off with the rc status until the manifest2 code got > some public testing first in another pre release. I don't feel > comfortable labeling 2.1 as "basically release ready" when only a dozen > people have tested something that critical. The manifest code doesn't have very many use cases so I'd expect that we would have hit most major problems by now (even with a small sample). Any necessary changes are likely to be small patches. As an alternative, we can cut the 2.1 branch at the point before manifest2 was merged (2.1_pre7, essentially). > The remaining feature I'd like to get into 2.1 is the tree-format-check > issue, but that could probably be slipped in in the rc phase (don't > really like that idea, but it's an option). I don't want to rush the development of new features such as manifest2 or the tree-format-check. We have a 2.1 branch that, in it's current state (2.1_pre7-r4, for example), provides significant benefits over the 2.0.x branch. By delaying 2.1's release for the addition of _new_ features, we run the risk of the release being delayed indefinitely by "just one more feature" syndrome. Personally, I'd rather have shorter release periods so that "just one more feature" syndrome becomes less of an issue. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENcpj/ejvha5XGaMRAlxzAKDEzo4fq1HtzZtGkhAAjviO+srchQCeN3Rb +30YB9/v9KwohcsgGHYQ7mE= =eHNd -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] 2.1 release candidate soon?
On Thu, 06 Apr 2006 13:13:34 -0700 Zac Medico <[EMAIL PROTECTED]> wrote: > So, I'd like to create 2.1 branch that is closed to mostly anything > except regression fixes and release it as portage-2.1_rc1 this > Saturday. We can continue to do ~arch releases of the development > branch (2.2 or whatever it becomes) every 2 weeks. Does now seem > like a good time for this transition? Your feedback would be > appreciated. I'd like to hold off with the rc status until the manifest2 code got some public testing first in another pre release. I don't feel comfortable labeling 2.1 as "basically release ready" when only a dozen people have tested something that critical. The remaining feature I'd like to get into 2.1 is the tree-format-check issue, but that could probably be slipped in in the rc phase (don't really like that idea, but it's an option). Marius -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] 2.1 release candidate soon?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I think the current quality level of the 2.1 branch is good enough to make it a release candidate. From my perspective, it seems like a waste of everyone's time to roll a 2.0.55 release when 2.1 is a perfectly good replacement (with lots of bug fixes relative to 2.0.54). I know there are probably some additional features that people would like to get into 2.1 before we make this transition. Despite this, I think that it's in everyone's best interest to retire the the 2.0.x branch as soon as possible so that it doesn't waste people's time. This transition doesn't necessarily mean that it's going to be "a long time" before some desired feature X is available in the stable version of portage. The next release after 2.1 (2.2 or whatever) doesn't necessarily have to be too far off in the future. So, I'd like to create 2.1 branch that is closed to mostly anything except regression fixes and release it as portage-2.1_rc1 this Saturday. We can continue to do ~arch releases of the development branch (2.2 or whatever it becomes) every 2 weeks. Does now seem like a good time for this transition? Your feedback would be appreciated. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENXZt/ejvha5XGaMRAqHmAJ0bBUU08XeyWe8vigWuU3228IvpWACg07u5 3Ncnef3STQ4s5t6PqCXviis= =nRr8 -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
