Re: FTPMaster meeting minutes

2010-09-25 Thread Joerg Jaspert
    Alexander helped our removal tool to gain a new option. From now on
    we can close bugs associated to a package when doing a sourceful
    removal. Obviously this is not enabled by default, but an option we
    have to select whenever appropriate (not all removals mean all bugs
    can be closed, like when its just a source rename), but this can
    greatly help the QA team.
 Will you also do the converse? unarchive and reopen appropriate bugs
 (based on the version tree) when a source package is reintroduced into
 the archive? Often a package gets orphaned and people who are
 interested in it don't notice until it gets removed from the archive
 and they then work on getting it re-uploaded.

No we wont, as this does not happen very often actually and is much more
unreliable than closing them. But what we will change is the removals
log entry to additionally have all the bug numbers listed which we
closed.

 21. untag pending bugs if a package is rejected
    As the bugs fixed in packages in the NEW queue are currently
    (semi-) automatically taged pending, Jan Hauke Rahm suggested to
    untag them, if a package get's rejected from NEW.  There's already
    a patch floating arround, which needs to be reviewed and merged.
 I assume you will also take over automatically adding pending tags to
 packages in NEW?

If someone patches that into the tools, yes.

-- 
bye, Joerg
Facts are meaningless. You could use facts to prove anything that’s even 
remotely true!


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5gijlbo@gkar.ganneff.de



Re: FTPMaster meeting minutes

2010-09-25 Thread Jan Hauke Rahm
On Sat, Sep 25, 2010 at 10:09:47AM +0200, Joerg Jaspert wrote:
  21. untag pending bugs if a package is rejected
     As the bugs fixed in packages in the NEW queue are currently
     (semi-) automatically taged pending, Jan Hauke Rahm suggested to
     untag them, if a package get's rejected from NEW.  There's already
     a patch floating arround, which needs to be reviewed and merged.
  I assume you will also take over automatically adding pending tags to
  packages in NEW?
 
 If someone patches that into the tools, yes.

I've been a bit silent about this. Maybe I find some time today.
Unfortunately, it's still python last time I checked. :)

Anyways, I'll have a look into adding pending tags as well.

Hauke

-- 
 .''`.   Jan Hauke Rahm j...@debian.org   www.jhr-online.de
: :'  :  Debian Developer www.debian.org
`. `'`   Member of the Linux Foundationwww.linux.com
  `- Fellow of the Free Software Foundation Europe  www.fsfe.org


signature.asc
Description: Digital signature


Re: FTPMaster meeting minutes

2010-09-24 Thread Raphael Hertzog
Hi Joerg,

thanks for those minutes, they were very interesting. I like that you're
working on integrating more stuff on the main archive. It's definitely
better than to have many separate archives. I do hope backports will be
a suite on the main archive at some point.

I have one comment and a question.

On Thu, 23 Sep 2010, Joerg Jaspert wrote:
 15. control-suite sanity
 Right now there is no sane version checking done when we import new
 data into a suite using c-s. This means that in theory the release
 managers could put packages/versions from any suite into testing
 (say, an oldstable version into testing, an experimental version
 into testing), completly violating any version constraint the suites
 have when processing uploads.
 This is currently solved/worked around by having a very big
 (virtual) hammer flying above the release/volatile peoples heads -
 should they ever make use of this capability and take version from
 elsewhere than the allowed source suite the import process would be
 stopped by us until we have all code changed to fully check it.

I can see the need of those checks as safety guards. They would be set
up on request of the people who decides of the policy... but why do you
present this as a hammer above their heads? If they're in charge of the
policy for a suite, they get to decide what goes in, no?

Anyway, I was wondering if there's some documentation about this interface
or if there's only the source code. I will have to look into this for
the CUT related suites so I might well just ask for a starter.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100924080850.gd5...@rivendell.home.ouaza.com



Re: FTPMaster meeting minutes

2010-09-24 Thread Hector Oron
Hello ftp-masters,

  Very impressive minutes! Thanks! I just wanted to do a couple comments:

On Thu, Sep 23, 2010 at 10:08:15PM +0200, Joerg Jaspert wrote:
 
 11. debian-ports
 Following a short chat I had with Aurelien Jarno about
 debian-ports.org and its archive, we discussed if FTPMaster could
 offer help with running such an archive.
 In general we aren't unhappy with it but we also do not want to end
 up the main force behind it. Together with the nature of the archive
 and the attached constraints (different architectures need to have
 the same source version - with different code/patches applied for
 example), the handling in dak is not straightforward nor entirely
 there yet. Most probably it will mean a set of mini archives, one
 per d-p architecture, and is as such attached directly to point 4
 and 5. When the work for those is done, it will be relatively easy
 to provide the support d-p needs. Exact conditions for such work
 still need to be worked out, but basically something along the line
 that FTPMaster does the technic while someone else is actually
 responsible for it. So 2 or more DDs need to sign up for the work
 per arch, if they drop out and noone replaces, it gets removed, etc.

I would not mind to help towards this goal and step up for whatever is needed, 
if you find it appropiate. Where do we need to sign up? :)

 18. Contents
 We are still working on this, mainly due to time constraints on the
 side of the main driver behind this. Should be ready soon.

What is Contents work about? Is it just packages content or are you working to 
provide a multimedia free/open content network (Debian Style). :D

Best regards,
-- 
 Héctor Orón

Our Sun unleashes tremendous flares expelling hot gas into the Solar System, 
which one day will disconnect us.

-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100924091045.ga31...@enorme



Re: FTPMaster meeting minutes

2010-09-24 Thread Joerg Jaspert

  2. Call for volunteers
 I volunteer to help the processing the NEW queue. I have a some experience in
 inspecting packages, through working on a team that maintains more than a
 hundred of them, and through my proposal for a chain reaction of copyright 
 file
 peer reviews (http://wiki.debian.org/CopyrightReview), that unfortunately did
 not attract followers.  You can check at the following page for my accuracy.
 http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=one-copyright-review;users=debian-le...@lists.debian.org

Thank you for volunteering.
We have just discussed it within the team and I have the unfortunate job
to tell you that existing members raised the won't fit card, ie. while
I am sure you could work with the existing members, not all of them
could or want with you.

As such I currently do not see you joining the team directly, but ...

 I also have a strong interest in data.debian.org, but probably more as a user
 than a team member. This said, if you need real-life cases for biology, do not
 hesitate to contact the Debian Med team.

... data.debian.org sounds good. What about helping out programming,
changing our code, to get earlier to it? That way I stand between you
and the team and you are helping out with a very valued contribution
that leads us to have data.debian.org earlier. :)

If so, to get you a basic understanding of the code so we have a base to
put our discussions on, could you please
 git clone https://ftp-master.debian.org/git/dak.git
and try getting familiar with it, at least the basic structure and ways
we do things?

A good learning example to find the way around would be to trace the
code path a package of a NEW upload is following in all the various
times we run a dak command on it, until the time it is finally removed
From the archive. That is, initial processing in the unchecked queue
(start with cron.unchecked from config/debian/), placing into NEW,
acceptance from there, installation into the archive, possibly moving to
a different suite, getting removed from the archive...)

-- 
bye, Joerg
buxy I wish mrvn stopped supporting 3.0 (quilt), it's a recipe for failure


pgp7kuixkAzl8.pgp
Description: PGP signature


Re: FTPMaster meeting minutes

2010-09-24 Thread Joerg Jaspert
On 12248 March 1977, Raphael Hertzog wrote:

 15. control-suite sanity
 Right now there is no sane version checking done when we import new
 data into a suite using c-s. This means that in theory the release
 managers could put packages/versions from any suite into testing
 (say, an oldstable version into testing, an experimental version
 into testing), completly violating any version constraint the suites
 have when processing uploads.
 This is currently solved/worked around by having a very big
 (virtual) hammer flying above the release/volatile peoples heads -
 should they ever make use of this capability and take version from
 elsewhere than the allowed source suite the import process would be
 stopped by us until we have all code changed to fully check it.
 I can see the need of those checks as safety guards. They would be set
 up on request of the people who decides of the policy... but why do you
 present this as a hammer above their heads? If they're in charge of the
 policy for a suite, they get to decide what goes in, no?

They decide, within the limits of the general archive. Which, using
testing as example, has the version constraints. testing takes from
unstable, and thats it. As I wrote it is a non-issue right now, but has
to be enforced if we want to easily add new suites and make sure the
technic actually ensures the general settings stay valid.

 Anyway, I was wondering if there's some documentation about this interface
 or if there's only the source code. I will have to look into this for
 the CUT related suites so I might well just ask for a starter.

package version architecture

dak ls -s testing -r . -f heidi gets you an idea.


-- 
bye, Joerg
_DeadBull_ ohne speicher, tastatur, mouse, pladde, monitor, also nur die
Hardware...


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tylfnfuz@gkar.ganneff.de



Re: FTPMaster meeting minutes

2010-09-24 Thread Joerg Jaspert
On 12248 March 1977, Hector Oron wrote:
 11. debian-ports
 [...]
 that FTPMaster does the technic while someone else is actually
 responsible for it. So 2 or more DDs need to sign up for the work
 per arch, if they drop out and noone replaces, it gets removed, etc.
 I would not mind to help towards this goal and step up for whatever is
 needed, if you find it appropiate. Where do we need to sign up? :)

When we are that far we will let d-d-a know about it for sure.

 18. Contents
 We are still working on this, mainly due to time constraints on the
 side of the main driver behind this. Should be ready soon.
 What is Contents work about? Is it just packages content or are you
 working to provide a multimedia free/open content network (Debian
 Style). :D

Its one of the steps we follow on our road to get more data into
projectb. In this case its what you can find in Contents files - you
find in projectb combined with we generate the files out of there.

(The next step then will be to do the same with Packages/Sources)

-- 
bye, Joerg
[...] when an Idea and a developer get laid, code awakes to the world, then
a Debian package is made and pulled in the unstable distribution[...]


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqw3nfrj@gkar.ganneff.de



Re: FTPMaster meeting minutes

2010-09-24 Thread Paul Wise
On Fri, Sep 24, 2010 at 4:08 AM, Joerg Jaspert jo...@ganneff.de wrote:

  9. dak rm
    Alexander helped our removal tool to gain a new option. From now on
    we can close bugs associated to a package when doing a sourceful
    removal. Obviously this is not enabled by default, but an option we
    have to select whenever appropriate (not all removals mean all bugs
    can be closed, like when its just a source rename), but this can
    greatly help the QA team.

Will you also do the converse? unarchive and reopen appropriate bugs
(based on the version tree) when a source package is reintroduced into
the archive? Often a package gets orphaned and people who are
interested in it don't notice until it gets removed from the archive
and they then work on getting it re-uploaded.

 21. untag pending bugs if a package is rejected
    As the bugs fixed in packages in the NEW queue are currently
    (semi-) automatically taged pending, Jan Hauke Rahm suggested to
    untag them, if a package get's rejected from NEW.  There's already
    a patch floating arround, which needs to be reviewed and merged.

I assume you will also take over automatically adding pending tags to
packages in NEW?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktik1uhycpfus4nfjra=er5g2jefofdwlkmkbp...@mail.gmail.com



FTPMaster meeting minutes

2010-09-23 Thread Joerg Jaspert
Hello world,

as you probably read on debian-project[1] there was a meeting of the
FTPTeam in Fulda last weekend. Mark, Alexander and myself met from
Friday til Sunday to discuss various topics we had on agenda - and to
discover multiple new restaurants all around my place. :)
And while I still miss out on Baklava (how can a turkish restaurant
seriously run out of that?) I thought we shouldn't have you miss
something that smells, tastes and looks like minutes, so here they are.
I'm sorry for all the length of it, but flipping between a simple We
met, we did something, sod off and this one, we somehow voted for a
slightly longer edition. Have fun. :)

[1] http://lists.debian.org/debian-project/2010/08/msg00314.html


 1. New FTPMaster
As you could already have read on d-d-a[2], there is a good reason to
send condolences over to Torsten, as we took his absence as the best
opportunity to promote him from FTP Assistant to FTPMaster. After all
he couldn't run away screaming as he wasn't attending.
  
[2] http://lists.debian.org/debian-devel-announce/2010/09/msg6.html
  
  
 2. Call for volunteers
As usual when posting longish mails to d-d-a (yes, I know we are on
-project) about our nice and beloved FTP Team, a call for volunteers
is on order. And here it is! Ever felt compelled to do the hard
groundwork? Ever wanted to help at a nicely central place inside
Debian? Or just want to write some python code and still look for a
good place to stick it in?
  
Here we are. Come join the Nav^Wteam. Just sign over there to the
right, or even easier, mail us. We won't bite you, thats for
sure. At least not right away. :)
  
The criteria are the same as always: You need to be a DD (except for
coding only, though it helps to know the usual flow of a package) and
you need to be able to deal with the existing team members.
  
An occasional flame should also not disturb you, if you are working
in the NEW queue you will stand between the people uploading and the
packages entering the archive, rejecting something is not always
liked much. (But you also get positive replies and thanks, to keep your
spirits up :) ).
  
And - if you get headaches when reading legal texts - we all do. But
it is needed and things like NEW are mainly about that, the ftpteam
is *the* one place to decide if something is ok for Debian to
distribute or not, and you will have to take this decision. (Yes,
there is more, but this is the master of the points you check).
  
Obviously the other points I made in earlier mails, like [3], still
apply too.
  
[3] http://lists.debian.org/debian-devel-announce/2010/03/msg3.html
  
   
 3. BYHAND
Turns out our BYHAND handling was broken since a few days. Seems like
we never got that back alive after Essen.
Shows how much BYHAND is used today, but with a perfect timing we had
someone place a BYHAND upload in the queue, so Mark took the
opportunity to fix it up.
  
We also decided we do no longer want to have BYHAND. We want those
things to be as automated as possible, and as such we invite the
remaining few users of BYHAND (about 2 packages) to talk to us, so we
can switch them over to the automated way other packages are using
(for example d-i).  This will help them as well as us as it'll mean
their packages go through more quickly and don't have to wait for us
to process them.
  
  
 4. Volatile archive
A while ago the volatile team approached us and asked if we can take
over their archive. We did not exactly take it over, but starting
with squeeze, the volatile suites will be integrated into the normal
ftp.debian.org mirrortree. This weekend we enabled squeeze-volatile
on ftp-master and setup the needed scripts so that the volatile team
can fill it with packages whenever needed.
Please note that the general handling of volatile starting with
squeeze is now different to the way volatile worked in the past. All
packages now have to pass stables proposed-updates queue before going
into volatile. Stay tuned, the volatile team will send out more
information about its handling later on, the exact policy how the
suite is run is with them, not us.
  
  
 5. Security archive
This is one blocker in the way to a stable squeeze release as this
archive is yet unable to process the dpkg v3 formats. Having recently
upgraded backports to the current dak codebase I now know what I have
to do with the security archive (same old code there), and my current
schedule means it should be done real soon now. There is one anomaly
in the security archive, namely the script used to actually release
DSAs, which needs lots of work (it's BAD, kay?!) to
continue working, but otherwise it should be the same amount of work
as getting backports working.
  
Additionally we 

Re: FTPMaster meeting minutes

2010-09-23 Thread Charles Plessy
Le Thu, Sep 23, 2010 at 10:08:15PM +0200, Joerg Jaspert a écrit :
   
  2. Call for volunteers

Dear Joerg, FTP team and everybody,

I volunteer to help the processing the NEW queue. I have a some experience in
inspecting packages, through working on a team that maintains more than a
hundred of them, and through my proposal for a chain reaction of copyright file
peer reviews (http://wiki.debian.org/CopyrightReview), that unfortunately did
not attract followers.  You can check at the following page for my accuracy.

http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=one-copyright-review;users=debian-le...@lists.debian.org

I also have a strong interest in data.debian.org, but probably more as a user
than a team member. This said, if you need real-life cases for biology, do not
hesitate to contact the Debian Med team.

Cheers,

-- 
Charles Plessy
Debian Med packaging team
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100924003826.ga3...@merveille.plessy.net