[Angstrom-devel] Maintenance of unstable feed

[Paul Sokolovsky]

Hello Koen,

Saturday, January 5, 2008, 2:56:29 PM, you wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> Paul Sokolovsky schreef:
> | Hello Koen,
> |
> | Friday, January 4, 2008, 5:29:16 PM, you wrote:
> |
> | []
|>> |   And it would be nice to have it more open for different developers,
|>> | and to use it as a staging/testing area for the things they work on,
|>> | they intend for stable feed addition, or users ask for the latter. In
|>> | this regard, asking that packages were built from OE-comitted recipes
|>> | and configs should be enough IMHO. Comments?
> |
|>> That leads to a mess faster than Harald can say "GPL violation". User
|>> built package should be exceptions, not the rule in the unstable feed.
> |
> |   Well, we don't talk about "users" here, but about developers who
> | already have SSH access to the server for upload. And it's just RFC
> | after all. I don't think the GPL matter is too limiting here, if
> | recipes are in OE mainline. It will be the same "source available on
> | request" as it is know.

> It's more a question of stopping "I disabled insane.bbclass because it
> threw some kind of error" type of packages ending up in the feeds. But
> as you say, it is marked 'unstable' for a reason. Another thing we
> should keep an eye on is that feeds are consistent across architectures
> and c libraries. So if someone uploads scummvm_0.13_armv5te.ipk we
> should take care that e.g. armv4t, ppc603, ppc405, etc also get that
> package. For angstrom 2008 that would mean also uclibc and eglibc.

> So my my proposal would be something like:

> * upload package to unstable
> * test
> * propose to add recipe name(s) to build-feed.sh
> * add recipe name(s) to build-feed.sh
> * build/upload/sort/update

  Fully agree with such procedure, just with the note that this should
not be the only way to get package into build-feed.sh. But that's
the sustained procedure on how to get arbitrary package X into the release
feed. For selected packages, votes of 2 developers should be enough,
per existing change management procedure.

> |    But if we don't invite people to cooperate on one well-maintained
> | repo, we push them to setup their own feeds and organize feed
> | graveyards like http://handhelds.org/moin/moin.cgi/IpkgFeeds

> Well, some people don't want to cooperate and set up their own (broken)
> feeds regardless of the policies and tools of the angstrom feeds. We
> should try to make it as easy as possibly and have well defined policies
> regarding package uploads, though.

  Yes. We just should try to make procedures which would motivate
people working on common goals instead of doing likely useless on
global scale stuff on their own. It's pretty common emotion for a
novice who just set up OE and built some packages, to throw them the
net way, truly believing that he helps other users. So, we are looking
for setting up an atmosphere where it will be common sense that giving
back and helping community would be instead requesting to add those
packages to unstable feed where it can get much wider dissemination
and attention than if the user hosted them himself.

  (Of course, what will be added to unstable feed are not user-built
packages, but ones built by an experienced developer; and when time
comes for release feed, no compromises at all - only clean-room
autobuild).

|>> My plan was to absorb new-index.sh into sort.sh and have it mark updated
|>> feeds so we can call update.php more intelligently. I ran out of time
|>> before completing that. Any volunteers?
|>> We probably should sort.sh in ~/bin as well to avoid version skew and
|>> nominating 'master copies'. Any volunteers?
|>> After that we can write an angstrom-feed-upload.bb that automates all
|>> that :)
> |
> |   Well, I'm not sure I understand fully what needs to be done and how.

> 1) make newindex.sh a function() in sort.sh so we only need one script
> 2) put that one script in ~/bin and add that to .bash_profile
> 3) make that one script keep track of new packages and call update.php
> only for updated feeds

  Btw, I've added to update.php support to run only on specific feed
(by URL). But what I found is that feed browser setup on serenity is
behind the code which is currently in mtn, so it's all dirty there
too... Currently back-hacked to work with that older codebase version
is under name of update2.php on serenity.

> 4) put that script in contrib

> | So, I'd start with bottom-up approach, and in the end would do
> | something else comparing to what you see it as. So, if you started with
> | it, please finish it too. But indeed, the scripts should be maintained
> | in well-known SCM, so mtn/contrib, and there's should be one copy in
> | well-known place.
> |
> |   .bb would be nice, but not a panacea,

> A recipe would give us easy access to two important things:

> 1) distro version
> 2) c library type

> | there should be tools to
> | maintain existing feeds (for example, rebuild indexes after removing
> | broken stuff).

> I'd prefer to fix 'broken stuff' the proper way by adding fixed packages
> with a bumped PR. Only if that isn't possible we should do a manual
> clean up. Manual cleanups tend to break upgrade paths :(

  Well, yes, for the release feed. Would be too high-in-clouds target
for unstable feed, IMHO. But I got your point - changes to unstable
feed should be RFCed too.

> regards,

> Koen




-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com