[maemo-developers] Repositories mess: conclusions and actions

From: Mikhail Sobolev mss at mawhrin.net
Date: Thu Nov 8 08:51:05 EET 2007
Hi Tim

On Wed, Nov 07, 2007 at 09:26:47AM +0100, Tim Teulings wrote:
> > 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.
This is probably what I still do not quite grasp.  There were a few
discussions where people were looking at the 'extras' repository from
different points of view, but I'd say those points are way too
different.  And the main problem with 'extras' is that there're not so
many applications in it.

I believe it's because of a simple challenge for developers: 'extras' is
expected to have good quality software ("good" is still to be defined
:)).  I saw quite a few comments (here, ITT, elsewhere) like "well, I'm
not 100% sure that my software is good enough to be put in 'extras', so
I'd rather make my own repo".  And as soon as the developer makes her
first repo for offering some alpha/beta software, it's gonna be
comparatively easy for her to _also_ create a repository next to the
first one where the stable/good stuff is made available.  As result
'extras' is underused.

The point of this plan is to explicitely make available a central place
where there's no such a vague restriction as "it must be good", so
developers instead of learning various tools (dpkg-scanpackages,
apt-ftparchive, reprepro, etc) would just learn one -- dput.

'extras' repository is coming pre-configured in Chinook and, since it's
disabled by default, the "normal" user would need to do something to
enable it.  'extras-devel' is _not_ pre-configured, so only brave souls
would add it to their catalogue list.

> 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"?
I think _some_ of the problems will be solved (see above).  Advantages?
I do not know.  So far alsmost nobody really followed up with 'yes,
that'd be great, [let's] do it!' message :)

> 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 :-/
Who is the group?  I'd say at the beginning we should forget about
groups :) and just make it working on 'I own this package, I move it'

As for step 3, it's actually a parallel step.  So my idea (and see, it's
still my idea, not our idea :)) might die at step 2 already.

> 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?
I do not know.

> What for example if we use
> http://mud-builder.garage.maemo.org/index.php
> instead?
I'll need to properly check it out.

> And please don't misunderstand we. I'm not saying "don't do this!", it 
> just a "good idea, but couldn't we do better with similar efforts?".
Well, my original proposal was to make it better only after we reach a
substantial checkpoint :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.maemo.org/pipermail/maemo-developers/attachments/20071108/ca6c76a0/attachment.pgp 
More information about the maemo-developers mailing list