On Sat, 2005-11-12 at 04:32 -0700, Duncan wrote: > I agree to some extent with both viewpoints, here. I think the viewpoint > of the "portage first" side is that we already have the "traditional" > stuff, the announce and dev list, the GWN, the forums, and "system > changing" announcements generally make it to most if not all those > already, but it's not working for some folks, and we want to see if > there's anything more that can be done, thus, the news-thru-portage > proposal. This viewpoint holds that since the portage angle is going to > form the core of things, since that's the main /new/ feature, implementing > it should be first, with the system designed around that, /then/ the > additional automated notifiers can be put into effect after the main > infrastructure is complete.
I think I'd prefer a more simultaneous rollout. The reason is fairly simple, and I have stated it before and nobody has refuted it, only ignored it. What about packages not installed? Also, it's going to take a while to go stable. During this time, users could also be using the other resources that would become available. Sure, we won't hit everyone, but it'll still be an increase from what we have now. Once the newer portage version with this feature goes stable, the number would go up again. I also agree that the "meat" of this proposal is portage-delivered news. > Valid viewpoint with some strong points supporting it. > > The traditional side first viewpoint recognizes that getting portage set > up and a new version rolled out to stable, after the usual level of > testing, with all these new features, is going to take awhile. This > viewpoint says nail down the reference format, create the dir in the > portage tree, set up the vetting process, and get started putting the > notices in the tree ASAP. This won't require rolling out a new version of > portage, since current portage will just sync the new dir, and ignore it. > At this point, we won't even have local portage doing the filtering, the > stuff will just be delivered in the portage tree sync and stay there, but > that's fine. Correct. > Once the "supply side" of the infrastructure is set up, that will allow > user submitted tools, outside of portage, a chance to go to it. Since > these separate tools don't have the Gentoo-vital duties that > emerge/portage does, these tools could be deployed relatively quickly, > with rather less testing. Likely, there'd fairly quickly be a couple of > unofficial ebuilds available on the user list and forums, much like the > several implementations of eclean, the one of which has now been chosen to > put into portage and is now in ~arch. Actually, gentoolkit but correct otherwise. > At the same time and also rather more rapidly than portage could evolve > and be tested, various devs could be working on the automated scripts that > would post the notices to the forums, announce and probably user lists, > and a web page, perhaps hanging off of packages.gentoo.org. Portage's > functionality, meanwhile, would come along in due time, likely rather > after several other delivery implementations are active, because of the > time required to implement it in an already functional and vital program, > without breaking anything, AND to properly test to be SURE nothing broke. Again, correct. This is why I don't think it is possible to "wait" for it to get into portage before launching it anywhere else. > This too is a valid viewpoint, with its strong points, the biggest weak > point being that because other delivery implementations will be using the > standard before portage gets nicely tested with it, it's possible > something unforeseen will come up with the reference format that makes it > more difficult to implement in what was after all the whole reason it was > put together in the first place -- portage. With other stuff already > using the format, it'd be far more difficult to tweak it if needed by the > portage implementation, without breaking the other stuff. > > Noting of course that I'm here, and I'm reading announce, and GWN, > therefore the proposal, while useful for me, isn't directly targeted at > me, and further noting that I'm not the one that's gotta do the > implementation, I can never-the-less post my "druthers" on the subject. > If I were implementing it, I'd probably go this second way. It'll get > stuff out there and working faster than the first way, and provided > appropriate care is taken in drafting the reference format and > implementing the initial delivery into the tree infrastructure, the risk > of disturbing portage's development in the area is relatively low. We get > the release early, release often going right away, and the other stuff > will naturally follow. > > > Another good reason to start with the 'common' things. The traditional > > ways some of your 100% of our users will be common with. Nothing new > > there for them. The portage way *is* new, and has never been done, hence > > they might have difficulties to "get it". > > I don't see that happening. Folks using Gentoo are already programmed to > use emerge for all their updates and to get new packages. There's little > else to "get". > > > Please remember that many of your 100% of our users hates software that > > doesn't work. It wouldn't be the first time a user decides never to use a > > piece of software again, because his/her first experience with it was very > > bad. > > Well, as it's shaping up, user's won't have a lot of choice -- the notice > of unread news will be output by portage any time they do much of anything > with it. Sure, they can set rsync-exclude on the news dir, but those that > are likely to know how to do that aren't normally going to be the ones the > proposal is targeting anyway. If they know how to do that, it's pretty > much a given that they know enough to sysadmin their own system, including > how to check for potential breaking updates, as things are. > > Of course, they could ignore the news alerts, but they'll be right in > their face, so they'll have to actively work at it to do so. > > That leaves rejecting emerge entirely, which pretty much means dumping > Gentoo. While I'm sure we all hate to see such a thing happen, the > reality is it's going to happen, with some, and there's not a lot we can > do about it. Meanwhile, we will have done what we could. > > All that said, I more or less agree with where you end up, that is, that > we (Gentoo) should get the approval infrastructure and delivery into the > tree set up as soon as possible, so that folks can begin implementing > other user-view delivery methods relatively quickly. Should that be done, > portage will probably end up being last to implement it's part, but by the > time it does, the other outlet methods will likely be decently on the way, > and chances are, the regulars in the forums and on the user list will have > already taken and run with the idea, so a not insignificant portion of the > userbase will already be familiar with the idea of news, before portage > ever delivers it. As they say in the performance arts, there's nothing > like playing to a warm house! > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman in > http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html > > -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
