On Wed, 2007-11-07 at 09:26 +0100, ext Tim Teulings wrote: > Hello! > > > I'd like to share a simple 5-step plan :) It seems that the discussion > > again somehow stopped. The first steps of the plan seem to be quite > > practical, so hopefully we can start implementing something. And I'd > > strongly suggest we proceed with step 5 only after having implemented > > steps 1-4 :) > > > Step 1: Create the repository itself > > Step 2: Create "promotion" interface > > Step 3: Add building facility > > Step 4: Making "promotion" interface a bit more sophisticated > > Step 5: Make it better? :) > > Wait a minute! > > Please rethink why we initially wanted a different behavior for the > extras repository. By initiating Step 1 and 2 immediately will we have > solved any of the problems we initially detected? Is there any advantage > to the current extras repository and will give it some momentum to > "the plan"? > Of course there is big advatage - development repository, where people can upload working but not ready to be released software to. Correct me if I'm wrong, but extras repository is considered as a repository for release quality software. It's not for developers, it's for users to install software from it.
For example before releasing mplayer to extras we always had 2-3 weeks of testing it by 'beta testers' which was not so simple to archive without having repository. It's even worse for projects which have more than one package to release (pymaemo/microb/RTComm for example). Another advantage of extras-devel is that developers would be able to test their betas together with other projects's packages. I think many users remember incompatibility issues between RTComm beta and GPE. This kind of things would never happened if developers would upload their packages in one repository and test them together. Unfortunately they didn't have this oppotrunity. > I'm not against acting with initial steps instead of discussing things > to the very end, but I think this suggestion is a too quick one. The > solution points to problems which were already be detected and not > clearly solved (especially the discussion about "who is the group" and > "how will they decide"). > > It also is easy to find people to "decide", but we definitely need > people who are willing to "improve the infrastructure" and do the hard > work. If we do not get them now, your idea might die a step 3, too :-/ > > I think there was some agreement on staging repositories similar to > debian together with some autobuilder mechanism. I think this is a basis > that would be better for start. Isn't there a chance to get such stuff > running in short time? We do have a few weeks time to set such stuff up. > We do not need a solution tomorrow. OR is there a down striped solution > (without staging) that would still give us some benefit? > > What for example if we use > > http://mud-builder.garage.maemo.org/index.php > > instead? The author has planed to use it for rebuilding upstream > packages but I think using it would give use more benefit than just > switch to totally manually mode (which we already have). It has not much > but at least more infrastructure. Can the author of mud please give his > opinion on my silly idea :-)? > > Or isn't there somebody who is able to set up real debian autobuilding? > > I think that as soon we have autobuilding, evaluating rating and bug > systems for staging should be possible. The advantage is, that the > information is already there. We have the rating under downloads and we > could use the garage bug tracking for each application (which would mean > that each application must have at least a garage project page). > Proposed plan also includes autobuilding as a step 3. I don't think autobuiling is a trivial task and people should wait for this to be done before they can actualy use extras-devel. Please, don't misuderstand me. I'm 100% for autobuilding, just don't want to wait for it. I have about 5-10 packages for IT2008 and I badly need development repository for them to put them to and test. Even without autobuilding and voting. And it seems that I'm not alone (http://lists.maemo.org/pipermail//maemo-developers/2007-August/011202.html) -- Ed Bartosh <[EMAIL PROTECTED]> Nokia-M/Helsinki _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
