[Pkg-e-devel] some items to discuss

[Daniele Favara]

On Thu, Nov 09, 2006 at 10:34:20PM +0100, Lut!n wrote:
> Hay there
> here's a list of items I think we should discuss about in a meeting
> 
>  * Team structure / organisation
> 	how do we organise ourselves to work ? Maintain as a team is good, but
> I think ppl could have some 'prefered' pkges though.
> 	maybe building the deb pkge won't be the only thing to do, so how would
> we split the tasks between us / defining what we have to an write a
> clear TODO

    + 1.

  i think we should use bzr to store debian trees and their branches, in
that way we can all work on the same packages. For ex i added all the
"watch" file, but i can't commit it, as i know Lutin did some work from
the last time i checked his debia source pkges.

So the item i'd propose here is the bzr repo tree, i'll write down a
wiki page and link it here.

> 
>  * Builds
> 	What system do we choose for the builds ? I'm using pbuilder, nomed
> told me about lp autobuilder network. pro / cons ?
> 	How do we build.Thiss will be scripted, but how. 

 the way debian and ubuntu do this is more or less the following:

 - Maintainer: # dput $host pkge_xyz_arch.(source_)changes
 - if 'source_changes':
   --> buildd incoming
     --> buildd asks wanna-build what pkgs need to be build
     --> buildd run sbuild
     --> if succesfull:
       --> upload/
   --> dput $dak_host pkge_xyz_arch.chages
     --> queue/unchacked
     --> if already not in the archive and changes file signed by a known
maintainer:
       --> queue/new
     --> queue/accepted
   --> ARCHIVE

Pro is that we're using the offcial debian way, and you can use pbuilder
locally anyway. It seems there is an ubuntu dedicated server ... so it's
possible to set up an Autobuilder Network

>I have a bash script,
> quite hackish, but I saw nomed is a python lover & pretty good in it, so
> maybe he has already something ready :)

Using that way any Maintainer can use his own scripts set, but i'm more
for using standard way.

 - generate a package
 - test a build locally
 - send it to the autobuilder network

Refs:

1] http://www.us.debian.org/doc/developers-reference/ch-resources#s-incoming-system
2] http://ftp-master.debian.org/
3] http://buildd.debian.org/
4] http://ftp-master.debian.org/new.html

Important!!: http://www.us.debian.org/devel/buildd/

> 	when do we build. We should define an update rhythm. 

i think we should have a dedicated meeting for this :) . So i just
deffere this. As it depends on what we decide for other topics

>My current policy
> is 
> 1. Not more than a once-a-week update. this is mostly for end-users,
> not qualified geeks. 

this is more or less the general idea

http://www.us.debian.org/devel/testing 

we should have branches. Let's go with some example.

We start packaging for *debian unstable*, everything cames from there
as:

- (ubuntu , debian testing)

all the pacakges build fine they are all debian policy compliant.

Then we start building for *ubuntu development branch* (aka feisty), we
shouldn't have problems as it derives directly from unstable.

We update packages in fesity and unstable when:

 - dependencies packages have been updated
 - bugs need to be solved

Here we can superseed the package version or just use patches, for
ubuntu this is valid untill *ubuntu development branch* is froozen, then
we should just use patches and we shouldn't superseed versions, when
this happen it's considered a "backport", we should avoid this.

(We coninue updating unstable obvioulsy so we're ready even for next
ubuntu releases)


> 2. Try the pkges before uploading, that should
> be replaced by a debian-style way to integrate the pkges as nomed said.
> Btw I don't think stabilizing by patches and such is a good idea, given
> tha amount of patches commited each day.
> 

an important point for me is to have the watch file within the debian
tree. If we're not using an official released tarball but it has been
generated from CVS we should write down a script and put it in the
debian dir (we can do that, the pkge is still debian policy compliant).

The script in this case should checkout the package from cvs (the revno
used for the commited debian dir), check Build-Deps and run make
checkinstall (this probably in a tmp dir) and generate the tarball to be
used for the package.

I can write it down.

>  * Other
> 	What will become the edevelop repo ? I don't want it to die. According
> to shadoi's stats we're pretty well know there and I don't think it'd be
> a good idea to move the primary mirror out of there. That needs to be
> discussed

I don't see any reason for that , we can have 10000000 archives and all
synced from the main one.

I have a shell at edevelop and you too, a cron job using rsync can do
it.

> 	TODO : we need to have a packaging policy for an easier scriptability,
> we should define it for the new pacakges to add.

see above (watch and script files)

> 		adding new pkges (mainly efl-based apps)
> 		downgrade epochs on enlightenment and emodules (will be done within a
> week)
> 
> Maybe we could define a meeting date depending on your availability

Sure!
 
-- 
Daniele Favara
address: Via Opisso 76/2 GE-Pegli 16156 ITALY
web: http://dsslive.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-e-devel/attachments/20061110/7d1135cc/attachment.pgp