[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Upcoming FTPMaster meeting



Hello world,

i just want to take the opportunity that everyone is watching the final
preparations for Squeeze to announce our next FTPMaster meeting. Your
beloved team of FTPMasters will meet from the 21st til 27th of March in
the LinuxHotel in Essen. During the weekend one of the wanna-build
admins will join in.

Similar to our last big meeting in Essen late in 2009 we again expect to
have the archive turned off for much of the meeting time. I think
expecting just something like "one dinstall per day, with packages
accepted shortly before" is reasonable, but maybe there is a day or ten
without even that. But we will keep you updated like we did last time,
it is hard to exactly pin down today what will happen when during that
week.


As we know that the services we offer are pretty central to Debian and
many people depend on what we do, we realize there are lots of people
whose work is closely related to ours. Should you be one of those and
run a service that can profit from something we can provide, or could
profit from certain changes on our side - and you want to kick that off
to get a better service from us: Please reply to me off-list and we can
see if we can work something out for you to join us for the weekend. (I
need a reason to see if it fits into the meeting and a half-way accurate
amount your travel will cost[1]). Currently we can plan for about 3 more
people.

[1] If you fly, Cologne or Duesseldorf are nearby. Frankfurt works too,
    especially good if you come in from far away. Obviously train takes
    a bit longer from there.
    From wherever you get in, the final train station you want to get to
    is called "Horst S-Bahnhof Essen (Ruhr)".


Attached below is a tentative agenda. This is an unsorted list and we
might not get to every point. We might also have missed any number of
points, if so feel free to tell us about them.


* Switch to use release codenames primarily inside dak, not
  testing/unstable/foo (if not done at release time already, which we
  try)

* Database "acl" set, ie. ability to merge security into main archive,
  but not have everyone see everything...

* Leaf packages. that is, the possibility of having small packages in
  the archive, without bloating the packages files as a "full package"
  would. Somehow, less information stored for them. Like only "Package",
  "Installed-Size", "Version", "FileName", "Size", "Sha1Sum" and one new
  "mainpackage:" which is simply the package name of the "full
  package". maybe a one-line description entry, but thats it.

  Tools like apt then take all the other missing information, including
  the long desc, from the mainpackage, and voila we get the possibility
  to have something like foo-config-blabla and foo-config-blubber
  without much bloat. (this will need design work done now but we won't
  be able to use it before wheezy or wheezy+1)

* pg9.0 fun (we want replication)

* buildd autosigning

* get rid of hurd (or discuss this)

* get rid of md5sum and one of the two shasums in packages files

* script point releases more. copy/paste from docs/README.stablefoo
  works, but script is nicer.

* Throwaway DD built .debs (well, let's have the fight^Wdiscussion)

* Built-Using infrastructure (for kernel udebs and so on)

* dinstall replacement (from bash off to python). look at ducks

* fix up build queue handling so security stuff works properly

* Merge the archives codes even more, maybe end up with only one config/
  directory, not one per archive

* data.debian.org

* Contents, Source-Contents

* Packages generation (needs lots of db stuff)

* Reduce the config file even more - more in the database

* Apropos the above, centralise dak's email handling / sending so it's
  easier to override (i.e. even from shell scripts use a dak wrapper for
  it)

* Documentation

* dak for squeeze (python 2.6, sqlalchemy 0.6, python-apt 0.7.100)

* explain the idea behind class ORMObject and friends

* remote interfaces: ORMObject has a json() method for easier debugging
  but might that be a first step to provide a (maybe readonly) REST
  interface to dak in the future?

-- 
bye, Joerg
Weaseling out of things is important to learn. It's what separates us
From the animals ... except the weasel.

Attachment: pgptiPkNmGp1r.pgp
Description: PGP signature


Reply to: