1 |
On Sat, 2005-11-12 at 04:32 -0700, Duncan wrote: |
2 |
> I agree to some extent with both viewpoints, here. I think the viewpoint |
3 |
> of the "portage first" side is that we already have the "traditional" |
4 |
> stuff, the announce and dev list, the GWN, the forums, and "system |
5 |
> changing" announcements generally make it to most if not all those |
6 |
> already, but it's not working for some folks, and we want to see if |
7 |
> there's anything more that can be done, thus, the news-thru-portage |
8 |
> proposal. This viewpoint holds that since the portage angle is going to |
9 |
> form the core of things, since that's the main /new/ feature, implementing |
10 |
> it should be first, with the system designed around that, /then/ the |
11 |
> additional automated notifiers can be put into effect after the main |
12 |
> infrastructure is complete. |
13 |
|
14 |
I think I'd prefer a more simultaneous rollout. The reason is fairly |
15 |
simple, and I have stated it before and nobody has refuted it, only |
16 |
ignored it. What about packages not installed? |
17 |
|
18 |
Also, it's going to take a while to go stable. During this time, users |
19 |
could also be using the other resources that would become available. |
20 |
Sure, we won't hit everyone, but it'll still be an increase from what we |
21 |
have now. Once the newer portage version with this feature goes stable, |
22 |
the number would go up again. |
23 |
|
24 |
I also agree that the "meat" of this proposal is portage-delivered news. |
25 |
|
26 |
> Valid viewpoint with some strong points supporting it. |
27 |
> |
28 |
> The traditional side first viewpoint recognizes that getting portage set |
29 |
> up and a new version rolled out to stable, after the usual level of |
30 |
> testing, with all these new features, is going to take awhile. This |
31 |
> viewpoint says nail down the reference format, create the dir in the |
32 |
> portage tree, set up the vetting process, and get started putting the |
33 |
> notices in the tree ASAP. This won't require rolling out a new version of |
34 |
> portage, since current portage will just sync the new dir, and ignore it. |
35 |
> At this point, we won't even have local portage doing the filtering, the |
36 |
> stuff will just be delivered in the portage tree sync and stay there, but |
37 |
> that's fine. |
38 |
|
39 |
Correct. |
40 |
|
41 |
> Once the "supply side" of the infrastructure is set up, that will allow |
42 |
> user submitted tools, outside of portage, a chance to go to it. Since |
43 |
> these separate tools don't have the Gentoo-vital duties that |
44 |
> emerge/portage does, these tools could be deployed relatively quickly, |
45 |
> with rather less testing. Likely, there'd fairly quickly be a couple of |
46 |
> unofficial ebuilds available on the user list and forums, much like the |
47 |
> several implementations of eclean, the one of which has now been chosen to |
48 |
> put into portage and is now in ~arch. |
49 |
|
50 |
Actually, gentoolkit but correct otherwise. |
51 |
|
52 |
> At the same time and also rather more rapidly than portage could evolve |
53 |
> and be tested, various devs could be working on the automated scripts that |
54 |
> would post the notices to the forums, announce and probably user lists, |
55 |
> and a web page, perhaps hanging off of packages.gentoo.org. Portage's |
56 |
> functionality, meanwhile, would come along in due time, likely rather |
57 |
> after several other delivery implementations are active, because of the |
58 |
> time required to implement it in an already functional and vital program, |
59 |
> without breaking anything, AND to properly test to be SURE nothing broke. |
60 |
|
61 |
Again, correct. This is why I don't think it is possible to "wait" for |
62 |
it to get into portage before launching it anywhere else. |
63 |
|
64 |
> This too is a valid viewpoint, with its strong points, the biggest weak |
65 |
> point being that because other delivery implementations will be using the |
66 |
> standard before portage gets nicely tested with it, it's possible |
67 |
> something unforeseen will come up with the reference format that makes it |
68 |
> more difficult to implement in what was after all the whole reason it was |
69 |
> put together in the first place -- portage. With other stuff already |
70 |
> using the format, it'd be far more difficult to tweak it if needed by the |
71 |
> portage implementation, without breaking the other stuff. |
72 |
> |
73 |
> Noting of course that I'm here, and I'm reading announce, and GWN, |
74 |
> therefore the proposal, while useful for me, isn't directly targeted at |
75 |
> me, and further noting that I'm not the one that's gotta do the |
76 |
> implementation, I can never-the-less post my "druthers" on the subject. |
77 |
> If I were implementing it, I'd probably go this second way. It'll get |
78 |
> stuff out there and working faster than the first way, and provided |
79 |
> appropriate care is taken in drafting the reference format and |
80 |
> implementing the initial delivery into the tree infrastructure, the risk |
81 |
> of disturbing portage's development in the area is relatively low. We get |
82 |
> the release early, release often going right away, and the other stuff |
83 |
> will naturally follow. |
84 |
> |
85 |
> > Another good reason to start with the 'common' things. The traditional |
86 |
> > ways some of your 100% of our users will be common with. Nothing new |
87 |
> > there for them. The portage way *is* new, and has never been done, hence |
88 |
> > they might have difficulties to "get it". |
89 |
> |
90 |
> I don't see that happening. Folks using Gentoo are already programmed to |
91 |
> use emerge for all their updates and to get new packages. There's little |
92 |
> else to "get". |
93 |
> |
94 |
> > Please remember that many of your 100% of our users hates software that |
95 |
> > doesn't work. It wouldn't be the first time a user decides never to use a |
96 |
> > piece of software again, because his/her first experience with it was very |
97 |
> > bad. |
98 |
> |
99 |
> Well, as it's shaping up, user's won't have a lot of choice -- the notice |
100 |
> of unread news will be output by portage any time they do much of anything |
101 |
> with it. Sure, they can set rsync-exclude on the news dir, but those that |
102 |
> are likely to know how to do that aren't normally going to be the ones the |
103 |
> proposal is targeting anyway. If they know how to do that, it's pretty |
104 |
> much a given that they know enough to sysadmin their own system, including |
105 |
> how to check for potential breaking updates, as things are. |
106 |
> |
107 |
> Of course, they could ignore the news alerts, but they'll be right in |
108 |
> their face, so they'll have to actively work at it to do so. |
109 |
> |
110 |
> That leaves rejecting emerge entirely, which pretty much means dumping |
111 |
> Gentoo. While I'm sure we all hate to see such a thing happen, the |
112 |
> reality is it's going to happen, with some, and there's not a lot we can |
113 |
> do about it. Meanwhile, we will have done what we could. |
114 |
> |
115 |
> All that said, I more or less agree with where you end up, that is, that |
116 |
> we (Gentoo) should get the approval infrastructure and delivery into the |
117 |
> tree set up as soon as possible, so that folks can begin implementing |
118 |
> other user-view delivery methods relatively quickly. Should that be done, |
119 |
> portage will probably end up being last to implement it's part, but by the |
120 |
> time it does, the other outlet methods will likely be decently on the way, |
121 |
> and chances are, the regulars in the forums and on the user list will have |
122 |
> already taken and run with the idea, so a not insignificant portion of the |
123 |
> userbase will already be familiar with the idea of news, before portage |
124 |
> ever delivers it. As they say in the performance arts, there's nothing |
125 |
> like playing to a warm house! |
126 |
> |
127 |
> -- |
128 |
> Duncan - List replies preferred. No HTML msgs. |
129 |
> "Every nonfree program has a lord, a master -- |
130 |
> and if you use the program, he is your master." Richard Stallman in |
131 |
> http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
132 |
> |
133 |
> |
134 |
-- |
135 |
Chris Gianelloni |
136 |
Release Engineering - Strategic Lead |
137 |
x86 Architecture Team |
138 |
Games - Developer |
139 |
Gentoo Linux |