On Wed, 01 Feb 2012, Olivier Berger wrote:
> I haven't checked for the rules of DEP elaboration, but may I suggest to
> add a notice in http://dep.debian.net/deps/dep2/ about where it is being
> discussed / how to provide feedback ?
Thanks, I added a small "feedback" section.
Cheers,
--
Raphaël
On Wed, 01 Feb 2012, Olivier Berger wrote:
> Do you intend to have such a system usable by / integrated with
> derivative distributions ?
I don't see any reason why the service could not be setup by derivatives
distributions if they wish, but honestly I don't expect them to install
it, much like I
On Wed, 01 Feb 2012, Olivier Berger wrote:
> Since alioth is used by quite a lot of Debian teams of individual
> maintainers, it seems to me that it would be great if the new system and
> alioth projects could be integrated somehow.
IMO the main "integration" will be to extract data from the VCS
Hi again.
On Fri, 27 Jan 2012 07:49:40 +0100, Raphael Hertzog wrote:
>
> PS: I start the discussion within the QA team but once the proposal is
> better formalized, I'll move the discussion to a wider audience (i.e.
> -devel or -project).
>
I haven't checked for the rules of DEP elaboration, b
Hi.
On Mon, 30 Jan 2012 09:18:20 +0100, Raphael Hertzog wrote:
> On Sun, 29 Jan 2012, Charles Plessy wrote:
>
> > Lastly, perhaps the DEP can discuss brifely why a new development is
> > necessary,
> > compared to using or extending existing tools, such as Launchpad or other
> > forges.
>
> Do
Hi.
On Fri, 27 Jan 2012 07:49:40 +0100, Raphael Hertzog wrote:
> Hello,
>
> I would like to design a new infrastructure that would replace the DDPO
> and the PTS, fix many current problems, and enable us to introduce new
> features to help package maintainers.
>
Here are a few comments on this
On Tue, 31 Jan 2012, Bernhard R. Link wrote:
> * Raphael Hertzog [120130 08:50]:
> > That's why I picked this approach which allows to start even if we don't
> > have buy in from some key teams and even if some maintainers are opposed to
> > the new approach.
>
> Well, as long as your approach is
On Tue, 31 Jan 2012, Bernhard R. Link wrote:
> Well, as long as your approach is some wild hack that will either lead
> to duplicate mail or racy sitatuation where mail can be lost I
> definitely know that I will be opposed.
Duplicates are vastly preferable over lost mail. We've been able to kill
* Raphael Hertzog [120130 08:50]:
> I won't deny that it would be cleaner if all the Debian services could
> send the information directly to this infrastructure only, but we had this
> discussion multiple times with the PTS already and we never seemed to have
> any sort of buy in from ftpmasters
On Mon, 30 Jan 2012, Raphael Hertzog wrote:
> >I think that the source package, and its VCS, are the
> >most appropriate canonical place for such information. Now that we
> >have “team uploads”, there is less needed to be listed in the Uploaders
> >field for occasional help, so the
On Sun, 29 Jan 2012, Charles Plessy wrote:
> - It would be great to integrate it with Debian Pure Blends, so that
>a maintainer knows that his package is part of one of them.
Why not but this is not something that needs to be part of the early
design.
> - I like the current workflow to deci
On Sat, 28 Jan 2012, Russ Allbery wrote:
> > ### Fixing the flow of information
>
> > In order to cleanly solve the problem of the information flow, and to get
> > rid of the hacks made everywhere to send a copy of the mails to the PTS,
> > packages would be (progressively) modified to indicate
>
Hi,
On Sun, 29 Jan 2012, Bernhard R. Link wrote:
> I think this way you get the worst of all possiblities combined.
>
> As maintainers might not use it, you need a copy for subscribed users
> anyway. But you also get a mail to the address for packages of
> maintainers that do (unless every inform
Hello Raphaël,
I like the idea of a Debian package maintenance hub that would extend and
replace the PTS, and consolidate available information in a single place. This
is especially useful as e-mail as a communication medium is declining. Spam is
abusing our mailboxes and our infrastructure, to
* Raphael Hertzog [120128 20:28]:
> Hum, we already have modified several Debian services (DAK, BTS) to send
> copies to the PTS. And I have mentionned that this copy sent to the PTS
> will let us use this new infrastructure also for packages where the
> Maintainer has not (yet) been updated.
>
>
Raphael Hertzog writes:
> High-level design of the new infrastructure
> ---
> ### Fixing the flow of information
> In order to cleanly solve the problem of the information flow, and to get
> rid of the hacks made everywhere to send a copy of the mails to
On Fri, 27 Jan 2012, Raphael Hertzog wrote:
> The current proposal is at the end in markdown format but you can also read
> it online in HTML format:
> http://dep.debian.net/deps/dep2/
I have updated it to take into account the comments received so far.
I put the complete text at the end and here
On Sat, 28 Jan 2012, Bernhard R. Link wrote:
> What I question is making the new address the new default for
> "Maintainer:". I'd rather only make it a possiblity (to replace
> mailing lists, for package groups, and for maintainers prefering it).
Well, the proposal doesn't force everybody to switc
* Raphael Hertzog [120128 18:42]:
> On Sat, 28 Jan 2012, Bernhard R. Link wrote:
> > makes that field useless. It would make more sense to get rid of that
> > field then[1]. (Though I'd prefer to make it only optional).
I think I placed my focus wrongly, thus made my point not very clear.
What I
On Sat, 28 Jan 2012, Bernhard R. Link wrote:
> Requiring the maintainer field to be set to a specific value effectively
> makes that field useless. It would make more sense to get rid of that
> field then[1]. (Though I'd prefer to make it only optional).
Well, it's not useless for a user who's loo
On Sat, Jan 28, 2012 at 03:18:51PM +0100, Raphael Hertzog wrote:
> On Fri, 27 Jan 2012, Jan Hauke Rahm wrote:
> > I'd like this new interface to be able to produce distribution wide
> > statistics regarding QA matters. I think this is covered by the
> > proposal.
>
> Can you elaborate?
>
> I don'
* Raphael Hertzog [120127 07:49]:
> High-level design of the new infrastructure
> ---
>
> ### Fixing the flow of information
>
> In order to cleanly solve the problem of the information flow, and to get
> rid of the hacks made everywhere to send a copy of the
Hi,
On Sat, 28 Jan 2012, Paul Wise wrote:
> This proposal has a lot of potiential to change Debian for the better,
> thanks a lot.
Glad to see that several persons are sharing my enthusiasm. :-)
> I had planned to work on the BTS IRC bot from #debian-devel-changes
> and enable it to forward stuf
Hi,
On Fri, 27 Jan 2012, Jan Hauke Rahm wrote:
> I'd like this new interface to be able to produce distribution wide
> statistics regarding QA matters. I think this is covered by the
> proposal.
Can you elaborate?
I don't see any problem with this in theory, but your description is
rather vague.
This proposal has a lot of potiential to change Debian for the better,
thanks a lot.
I had planned to work on the BTS IRC bot from #debian-devel-changes
and enable it to forward stuff to more channels based on package name,
but it sounds like this proposal obsoletes that bot too.
I guess this p
Hi Raphaël and everyone,
On Fri, Jan 27, 2012 at 07:49:40AM +0100, Raphael Hertzog wrote:
> I would like to design a new infrastructure that would replace the DDPO
> and the PTS, fix many current problems, and enable us to introduce new
> features to help package maintainers.
First of all, I'd li
On Fri, Jan 27, 2012 at 08:18:55AM +0100, Lucas Nussbaum wrote:
> - the machine is upgraded to something recent (currently it's a machine
> which was obsoleted by HP in 2005, so there's some margin for
> improvement). There's work in progress on that by DSA.
If I would have a vote on this I wo
On Fri, Jan 27, 2012 at 07:49:40AM +0100, Raphael Hertzog wrote:
> PPS for Zack: I have extended the document since the version that you
> reviewed.
Thanks. In the current form it completely addresses my concerns, still
without completely sacrificing the commitment part which is mentioned as
a so
On Fri, 27 Jan 2012, Lucas Nussbaum wrote:
> I think that one thing that is missing is integration with VCS-based
> maintenance. In that context, replacing PET would be a worthwhile goal
> too.
I agree but I put this in the interesting extensions that we can build on
top of it once we have it.
I
On 27/01/12 at 07:49 +0100, Raphael Hertzog wrote:
> Hello,
>
> I would like to design a new infrastructure that would replace the DDPO
> and the PTS, fix many current problems, and enable us to introduce new
> features to help package maintainers.
>
> I decided to use a DEP for this because I be
30 matches
Mail list logo
