Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)

2024-04-07 Thread Andreas Tille
Am Thu, Apr 04, 2024 at 10:14:59AM -0700 schrieb Soren Stoutner:
> On Thursday, April 4, 2024 5:32:45 AM MST Andreas Tille wrote:
> >[ ] Its not acceptable, don't do that
> >[ ] We should discuss this on debian-devel, possibly do some GR
> >before things like this are permitted
> >[ ] Wait one week before uploading
> >[X] Wait one day before uploading
> >[ ] Just upload provided you care for any break your action might
> >have caused.
> >[ ] ???
> 
> Given the circumstances, I think waiting one day before uploading is 
> appropriate.
> 
> I also feel that asking this question on this list is appropriate.  It is 
> insightful in helping me understand how Andreas would approach being the DPL, 
> thus informing my vote.

Summarising my question about how to deal with an example RC bug that affects
some dependency tree of some team:

   1. Prefer NMU which solves the problem quickly.  I do not volunteer to
  do this since I do not consider it sustainable in the said situation.
   2. Prefer package salvaging (which I did now #1068561 but its a lengthy
  process that will trigger another series of testing removal warnings
  in between)
   3. Two responses would agree to an alternative way which are not backed up
  by any procedure we agreed upon so I will not do this.  I wonder whether
  we can use this as some input to simplify / shorten the salvage process
  or whether we should move on as before.


Additional remark: When reading the PackageSalvaging FAQ[1] I realised
that my way to talk about examples might be considered finger pointing
no matter whether I write that this is not intended.  I understand I was
wrong here and I'm sorry about doing so.  I do not intend to do this in
future any more.

Kind regards
Andreas.


[1] https://wiki.debian.org/PackageSalvaging#FAQs

-- 
https://fam-tille.de



Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)

2024-04-07 Thread Andreas Tille
Hi again,

Am Sat, Apr 06, 2024 at 09:26:25AM +0200 schrieb Tobias Frost:
> > I want to be able to immediately respond to future problems in this
> > package.  I'm fine with putting Debian Med team as maintainer, but not
> > my personal ID (maximum as Uploader since I do not have any personal
> > packages).
> > 
> > Do you think this would be the appropriate action (which I personally
> > would even prefer over debian/ space)?  The conservative criteria
> > are fulfilled.
> 
> Yes, (if your name is in Uploaders:) this is is fine.

I've filed ITS bug #1068561.

Kind regards
 Andreas.

-- 
https://fam-tille.de



My stance on single-person maintainership

2024-04-07 Thread Andreas Tille
Hi,

on debian-private which I can't quote here I was asked, whether I would
continue 'going for forced “team” maintenance'.  My answer was as
following:

I stick to the sentence of my platform: 'If you think single
maintainership of packages is the right way to cope with future problems
for Debian you should probably rank me below "None of the above".'

I don't see both statements equivalent.  My statement is about a vision
voters are sharing (or not).  Your statement is about forcing something
that neither can be forced nor has the DPL any power to force something
(per constitution).

What I like to accomplish as a first step is drafting a GR about the
mandatory usage of Salsa as some first step to enable some effective way
in "Building redundancy" (the paragraph which contains the sentence
above).  Scott asked on debian-vote: What specific powers of the DPL
will help you realize this goal?[1]  I might like to add to the answer I
gave to this question:  Probably all other work as DPL might rather keep
me away from working on this.  However, I like to encourage interested
people (and due my campaign I sensed a lot of interest), to draft a
sensible GR about this topic.  Your choice you consider me below NOTA
right now or vote "Further discussion" later.

I consider the mandatory usage of Salsa important to accomplish Debian
wide changes.  Janitor is nice, its polishing things but I see way more
potential.  Just assume NMUs of time_t 64Bit transition could have
operated on Salsa by pulling everything from there, do automated changes
and also pushing back what was uploaded.  This could have saved all
parties involved quite some time.  Five years ago Michael Stapelberg has
explained the disadvantages of the "Change process in Debian".  I fully
subscribe what Michael wrote and I did not noticed any relevant change
since that time.  Other advantages like tag2upload, a defined CI process
etc. come to mind.
 
I think we all agree that Git is a great collaboration tool and we have
Salsa as platform that can stir fruitful cooperation.  I'd be happy if
we could all agree that the consequent usage of Salsa has technical
advantages for everybody.

In short: While I personally prefer team maintenance I see the mandatory
usage of Salsa just as a precondition for this with some additional
advantages no matter how many people are working on some package.  I
rather like to build the foundation for some future DPL who might share
my mindset about teams by at the same time standardise the way we handle
our source code for extra profit.

Since I've frequently seen the XZ case as a dead beat argument against
co-maintenance:  If XZ had been maintained by more than one person from
the outset, it would have been less susceptible to attacks leveraging
social pressure, preventing someone from stepping in at an inopportune
moment.  The fact that you can tweak the case as an argument for both
sides might show that it does not really help here.

I don't want to hide that I'm personally in favour of team maintenance
since I have made overwhelming positive experiences with this - and
there were also some negative experiences.

Kind regards
   Andreas.

[1] https://lists.debian.org/debian-vote/2024/04/msg00016.html
[2] https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/
[3] https://lists.debian.org/debian-r/2024/03/msg0.html

-- 
https://fam-tille.de



- Ende weitergeleitete Nachricht -

-- 
https://fam-tille.de