Bikeshedding

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Bikeshedding

Anthony Towns-5
Hi *,

"More of a comment than a question..."

On Wed, Mar 20, 2019 at 06:17:00AM -0400, Sam Hartman wrote:
> I am disappointed when people leave bitter and disheartened.

That's still kind-of better than if they're bitter and disheartened,
but won't go away though!

One of the things I often think helps let people avoid getting bitter
and disheartened despite differences of opinion is the ability to carve
out their own space where they can do what they want. For the problems
we used to have -- "vi vs emacs", "gnome vs kde", "exim vs postfix vs
qmail", "systemd vs sysv", "ppc vs x86", "amd64 vs ia64" -- we've been
really good at letting people with different opinions get their way
without that causing problems for anyone else. To me "main vs non-free"
and even "stable vs testing vs unstable" match with that philosophy too,
if not as well. [0]

But we've got lots of new problems where that doesn't work so well:
people who want to quickly develop stuff with random libraries vs people
who don't want to run "curl http://... | sudo bash"; people who want to
make big changes to everything in the distro vs people who don't want
their packages to get broken due to the latest fad, etc.

A few years ago, we had a plan that (IMO) would have made a big
improvement there:

  https://lists.debian.org/debian-devel/2013/05/msg00131.html
  https://lists.debian.org/debian-devel/2015/09/msg00340.html
  https://lists.debian.org/debian-devel/2015/09/msg00404.html

Did anything happen to that? (Or perhaps, that's better phrased as:
did anything cause it to stall other than ENOTIME?) I'm guessing not? [1]

Unless the things that caused it to stall were legal concerns or a need
for separated hosting/mirror infrastructure, that might not be something
the DPL can make much better. Perhaps if Joerg quits DAM due to being DPL
and ftpmaster due to having to re-delegate it, the combination of those
might leave him with more time for dak development despite also being DPL?

FWIW, I think giving every DD their own bikeshed that they can paint
whatever colour they like would be by far the biggest improvement possible
in Debian today. [2]

As a result, I kind of disagree with Joerg's statement in his platform
that "As the DPL is not the lead of actual technical development, it is
not for the DPL to find technical solutions for the challenges we face"
-- I think spending time making a huge technical improvement for the
project, like bikesheds, would be the best way to demonstrate leadership
(whether done by the DPL or not), and honestly I'd be more impressed
seeing a DPL do that compared to a DPL spending a year's time focussed
on mediating disputes and PR. Obviously, YMMV.

Anyway, some explicit questions if that's any help:

 * Debian is made up of a lot of policies, and rules; and often has a
   lot of arguments and hurt feelings. Debian's also made up of a lot of
   genius (and admittedly not so genius) code and technical achievements.
   Usually, DPLs seem to spend all their time dealing with policies and
   conflicts, rather than technical stuff.

   Do you think it makes sense to put some real effort in moving the
   balance the other way? If so, how?

 * Do you think bikesheds are actually a bad idea, or know of any other
   particular roadblocks in the way of making bikesheds happen? If Joerg
   is too busy to do it, do you have any ideas on how others could make it
   happen (within Debian, not as a derivative of some sort)? If elected,
   would you help remove those roadblocks?

 * As far as technical projects go, is there anything you think would
   have more of an impact than having bikesheds available to every DD?
   (Or, if you think bikesheds are a bad idea, what's the biggest positive
   impact technical project, in your opinion?)

Cheers,
aj

[0] I think the idea of mandating everyone use "dh" is a bit weird here;
    if we made rules like that, then everyone would have been forced to
    use debhelper or debmake and we would have had to have a big policy
    debate before rolling it out, rather than "just doing it"... I
    think that's the sort of setup that would have prevented "dh" ever
    getting written in the first place, and I don't think it's far off
    from saying it's the sort of policy that caused dh's inventor to
    move on from Debian...

[1] https://lists.debian.org/debian-dak/2018/04/msg00039.html
    https://lists.debian.org/debian-dak/2018/04/msg00040.html

[2] For example, want to do a big change but are stymied because some
    maintainer isn't using dh and doesn't want to manually update their
    package? Fork the entire archive into your own bikeshed and just do
    it. After you've fixed the bugs, it's a lot easier to say "here's a
    working solution, please consider the patches", and if there's still
    opposition, a lot easier to have a useful debate on a list or with
    the tech ctte about which is the best approach when they're both
    implemented. And in the meantime anyone who cares can just use the
    bikeshed, so they don't have to wait.

Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Jonathan Carter (highvoltage)-2
Hi aj

On 2019/03/29 06:32, Anthony Towns wrote:

> FWIW, I think giving every DD their own bikeshed that they can paint
> whatever colour they like would be by far the biggest improvement possible
> in Debian today. [2]
>
> As a result, I kind of disagree with Joerg's statement in his platform
> that "As the DPL is not the lead of actual technical development, it is
> not for the DPL to find technical solutions for the challenges we face"
> -- I think spending time making a huge technical improvement for the
> project, like bikesheds, would be the best way to demonstrate leadership
> (whether done by the DPL or not), and honestly I'd be more impressed
> seeing a DPL do that compared to a DPL spending a year's time focussed
> on mediating disputes and PR. Obviously, YMMV.

Well, there are two sides to that coin.

In the literal sense I tend to agree with Joerg on that one, the DPL
shouldn't lead actual technical development.

Having said that, the DPL does tend to have a lot of attention that can
be used to bring focus and limelight to a project, and I think in that
way a DPL could use that to help keep momentum and focus for a
project-wide goal. However, I think such goals need to go through our
usual processes. If I were to become DPL, I would very likely make use
of the DEP process and get an approved DEP for something like bikesheds
before driving that. I don't think it's the DPLs place to just chase the
ideas that are cool to them (although, of course it does help if that's
aligned with the project in terms of DPL enthusiasm), but it's important
that the DPL spends energy where the project needs it with the backing
of the members in the project.

>  * Debian is made up of a lot of policies, and rules; and often has a
>    lot of arguments and hurt feelings. Debian's also made up of a lot of
>    genius (and admittedly not so genius) code and technical achievements.
>    Usually, DPLs seem to spend all their time dealing with policies and
>    conflicts, rather than technical stuff.

Heh, you've intermingled quite a few things there. I'll reduce it to
this: policies and rules are our friends, they help keep things simple
and help move us forward. Our rules aren't sacred text carved out on
stone tablets either, they exist to serve our project. When they fail in
doing so, we should look at enhancing them.

I agree that the DPL shouldn't only focus on minutia, and have also
addressed that in my platform. However, it has been unfortunate that
some of the previous DPLs had little choice in the matter due to
circumstances during their terms.

>  * Do you think bikesheds are actually a bad idea, or know of any other
>    particular roadblocks in the way of making bikesheds happen? If Joerg
>    is too busy to do it, do you have any ideas on how others could make it
>    happen (within Debian, not as a derivative of some sort)? If elected,
>    would you help remove those roadblocks?

I don't think it's a bad idea, although personally I'm not fond of the
nomenclature. As DPL I would certainly support it. Sprints seem to have
proven themselves in Debian to get blocks of work that's otherwise
difficult to co-ordinate done. As DPL I would be happy to approve
funding for such sprints, but even then you'll need the people who are
willing to do this work to begin with.

>  * As far as technical projects go, is there anything you think would
>    have more of an impact than having bikesheds available to every DD?

There are probably too many to mention. As I see it, bikesheds solve a
few very specific problems, but I can't see a reason to think of it as
the most important project in Debian right now.

Having said that, I think people who care about it should keep the
conversation going. Schedule IRC meetings, schedule BoFs at DebConf
(CfP's are open now btw), make notes about those in etherpads and put
together a kick-ass DEP that everyone can get behind. There are plenty
of good ideas that die quietly in mailing list threads, if an idea is
important and people care about it, they will get behind you if you put
the energy in to it.

-Jonathan

--
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Sam Hartman-3
In reply to this post by Anthony Towns-5
>>>>> "Anthony" == Anthony Towns <[hidden email]> writes:

    Anthony> Hi *, "More of a comment than a question..."
    >> I am disappointed when people leave bitter and disheartened.

    Anthony> That's still kind-of better than if they're bitter and
    Anthony> disheartened, but won't go away though!

Yeah.
I actually think a huge huge improvement in Debian in the last five
years or so is that culturally we've encouraged people to analyze
whether they are happy and stop if they are not.

More often than I'd like they go away bitter and that's unfortunate both
because it's not great for the people departing and because it tends to
spread bad blood around.

And when it's a sign of something where we could have fixed the problem
and kept people happy, well, it makes me want to fix the problems.

    Anthony> But we've got lots of new problems where that doesn't work
    Anthony> so well: people who want to quickly develop stuff with
    Anthony> random libraries vs people who don't want to run "curl
    Anthony> http://... | sudo bash"; people who want to make big
    Anthony> changes to everything in the distro vs people who don't
    Anthony> want their packages to get broken due to the latest fad,
    Anthony> etc.

    Anthony> A few years ago, we had a plan that (IMO) would have made a
    Anthony> big improvement there:

    Anthony>   https://lists.debian.org/debian-devel/2013/05/msg00131.html
    Anthony> https://lists.debian.org/debian-devel/2015/09/msg00340.html
    Anthony> https://lists.debian.org/debian-devel/2015/09/msg00404.html

With respect, I don't actually think bikeshedding helps that much with
the sort of situations where people want the project to choose one
thing.
It allows people to try things out, it allows people to have technical
data for their experiments more easily.

However, ultimately, they still want to get stuff into Debian.
And ultimately, they don't want to have to fork huge chunks of Debian to
do the stuff they want.

And I don't think that it solves the real emotional issues I'm seeing
more and more in the project.  I have high confidence that I'm not alone
in feeling hurt when things I value aren't even considered by others.
Having my own little playground doesn't really make me feel much better
when my needs for respect and community are not met.
A sufficiently poorly received email can drive away my motivation for a
day and can significantly reduce my willingness to work on some aspect
of Debian.
I am perhaps less thick-skinned than average, but I know it's a real
issue because I hear others talking about it and because I see the same
signs of disengagement I find in myself when I see others receive
something that is hard to take.

So, I think bikeshedding is valuable, and can help some, but I don't
think it's nearly as valuable as you do.


The good news is that we actually have a lot of the infrastructure you
need for this.  As an example, the salsa CI team has a pipeline that
builds packages to run several of our quality tests against.
I know many people who have independently adopted similar work flows and
attached them to repositories to give something very similar to what
you're talking about.

Interestingly, when the bikeshedding project first came out, I found it
really exciting and thought it was going to be a game changer.  These
days though, reprepro, mini-buildd, aptly and others are strong enough
tools that when I've had something I wanted to share enough to actually
make it available, the infrastructure just hasn't been a problem.
I realize that it still is an issue for newcomers, and that it still is
valuable, but I think that tool improvements have taken off some of the
pressure.  The good news of course being that we can use those tool
improvements in actually deploying something.

That's especially true if we're willing to be incremental.  Perhaps the
first version only builds for amd64 and one or two other architectures.
Perhaps the first version has adequate but not great key management for
release keys.  Perhaps the first version uses tools other than dak and
buildd that aren't quite as robust.
I'm not at all sure that would be a problem.


    Anthony> As a result, I kind of disagree with Joerg's statement in
    Anthony> his platform that "As the DPL is not the lead of actual
    Anthony> technical development, it is not for the DPL to find
    Anthony> technical solutions for the challenges we face" -- I think
    Anthony> spending time making a huge technical improvement for the
    Anthony> project, like bikesheds, would be the best way to
    Anthony> demonstrate leadership (whether done by the DPL or not),
    Anthony> and honestly I'd be more impressed seeing a DPL do that
    Anthony> compared to a DPL spending a year's time focussed on
    Anthony> mediating disputes and PR. Obviously, YMMV.

I agree that the DPL has a job in leading technical work.  I think the
DPL can work to figure out how things are getting blocked and help
remove blocks.  The DPL has a lot of tools to do this.  The DPL can lead
discussions.  When something is not going to get a project wide
consensus, the DPL can delegate actually making the decision.
Alternatively, when it's the right thing, the DPL can ask the TC or
project as a whole to vote to actually make a decision.  When people are
getting in the way the DPL can work to resolve problems or re-delegate
so that the right set of people are working on the problem.


Also, to be clear, my hope is to do better than spending a year
mediating disputes.  My hope is to improve the quality of dispute
resolution we have by helping the people who come to the DPL for dispute
resolution improve their approach to disputes.  My hope is to also set
up a better structure to handle dispute resolution so it's not just the
DPL handling that.

    Anthony> Anyway, some explicit questions if that's any help:

    Anthony>  * Debian is made up of a lot of policies, and rules; and
    Anthony> often has a lot of arguments and hurt feelings. Debian's
    Anthony> also made up of a lot of genius (and admittedly not so
    Anthony> genius) code and technical achievements.  Usually, DPLs
    Anthony> seem to spend all their time dealing with policies and
    Anthony> conflicts, rather than technical stuff.

    Anthony>    Do you think it makes sense to put some real effort in
    Anthony> moving the balance the other way? If so, how?

I think it makes a lot of sense to get the DPL doing more to help
unblock technical work and lead technical discussion.  I think the DPL
should not lead by preferring a specific solution, but rather by
bringing attention to problems that need solving and helping drive the
discussion and decision and work facilitation process.

That said, I think conflict resolution is really important in keeping a
community strong and healthy.

I don't think having the DPL write code is often the best choice.  I do
think it's critical that the DPL understand the technology and be able
to talk and think coherently about the code involved, but actually
spending a year hacking doesn't make that much sense to me for the DPL.

    Anthony>  * Do you think bikesheds are actually a bad idea, or know
    Anthony> of any other particular roadblocks in the way of making
    Anthony> bikesheds happen? If Joerg is too busy to do it, do you
    Anthony> have any ideas on how others could make it happen (within
    Anthony> Debian, not as a derivative of some sort)? If elected,
    Anthony> would you help remove those roadblocks?

I don't think bikesheds are a critical priority.  I think things that
limit our workflow when contributing to the big debian are higher
priorities.  I'm much more interested in helping move the git source
package and better workflows involving salsa projects forward, because I
think they will make Debian easier to contribute to and reduce
cross-team and intra-team frustrations as we do our work.

I'd be happy to help bikesheds along by working with someone who wanted
to drive that work and lending DPL help/delegation where needed.
Would you be interested in doing a deep dive into figuring out where
they are now and trying to build a plan to get from where we are to
something that works?


    Anthony> [0] I think the idea of mandating everyone use "dh" is a
    Anthony> bit weird here; if we made rules like that, then everyone
    Anthony> would have been forced to use debhelper or debmake and we
    Anthony> would have had to have a big policy debate before rolling
    Anthony> it out, rather than "just doing it"... I think that's the
    Anthony> sort of setup that would have prevented "dh" ever getting
    Anthony> written in the first place, and I don't think it's far off
    Anthony> from saying it's the sort of policy that caused dh's
    Anthony> inventor to move on from Debian...

    Anthony> [1]
    Anthony> https://lists.debian.org/debian-dak/2018/04/msg00039.html
    Anthony> https://lists.debian.org/debian-dak/2018/04/msg00040.html

    Anthony> [2] For example, want to do a big change but are stymied
    Anthony> because some maintainer isn't using dh and doesn't want to
    Anthony> manually update their package? Fork the entire archive into
    Anthony> your own bikeshed and just do it. After you've fixed the
    Anthony> bugs, it's a lot easier to say "here's a working solution,
    Anthony> please consider the patches", and if there's still
    Anthony> opposition, a lot easier to have a useful debate on a list
    Anthony> or with the tech ctte about which is the best approach when
    Anthony> they're both implemented. And in the meantime anyone who
    Anthony> cares can just use the bikeshed, so they don't have to
    Anthony> wait.


signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Joerg Jaspert
In reply to this post by Anthony Towns-5
On 15356 March 1977, Anthony Towns wrote:

> Did anything happen to that? (Or perhaps, that's better phrased as:
> did anything cause it to stall other than ENOTIME?) I'm guessing not?
> [1]

ENOTIME. And ENOONEELSEINTERESTEDINCODING.

> Unless the things that caused it to stall were legal concerns or a need
> for separated hosting/mirror infrastructure, that might not be something
> the DPL can make much better. Perhaps if Joerg quits DAM due to being DPL
> and ftpmaster due to having to re-delegate it, the combination of those
> might leave him with more time for dak development despite also being
> DPL?

Thats an interesting take on it.

> As a result, I kind of disagree with Joerg's statement in his platform
> that "As the DPL is not the lead of actual technical development, it is
> not for the DPL to find technical solutions for the challenges we face"
> -- I think spending time making a huge technical improvement for the
> project, like bikesheds, would be the best way to demonstrate leadership
> (whether done by the DPL or not), and honestly I'd be more impressed
> seeing a DPL do that compared to a DPL spending a year's time focussed
> on mediating disputes and PR. Obviously, YMMV.

I stay with my statement. The DPL is not the lead of actual technical
development. But that does not exclude a DPL from being the lead of
actual technical development - by the virtue of the person thats DPL at
the time also being in a team where that development happens.

Maybe obscure, but I think of that as two hats.

>  * Debian is made up of a lot of policies, and rules; and often has a
>    lot of arguments and hurt feelings. Debian's also made up of a lot of
>    genius (and admittedly not so genius) code and technical achievements.
>    Usually, DPLs seem to spend all their time dealing with policies and
>    conflicts, rather than technical stuff.

>    Do you think it makes sense to put some real effort in moving the
>    balance the other way? If so, how?

I think we do have a good amount of policies and sometimes too much of a
fear to just go and break one if its sensible. Also, everyone likes to
define sensible different.

And yeah, we discuss things to death way too often.

Unsure how to get that pendulum moving into the other direction, and for
how far.

>  * Do you think bikesheds are actually a bad idea, or know of any other
>    particular roadblocks in the way of making bikesheds happen? If Joerg
>    is too busy to do it, do you have any ideas on how others could make it
>    happen (within Debian, not as a derivative of some sort)? If elected,
>    would you help remove those roadblocks?

I think they are a pretty nice one and would still love to see them.

Others: The hard way, join the ftp team, work your way up until you have
the powers to just go and do em. Takes years.

Better: First off it needs code finished. There is a branch, bikeshed, I
just pushed it to salsa. That does need to get a recent master $magiced
(merge, rebase, whatever) in, then cleaned up and finished off. Anyone
who understands python can start working on that. A bit of understanding
the archive will help, sure, but first off, its python code.
That will take a while before it does need an ftpmaster. Any of us,
though I am happy to be the contact and think Ansgar won't run away
screaming either.

>  * As far as technical projects go, is there anything you think would
>    have more of an impact than having bikesheds available to every DD?
>    (Or, if you think bikesheds are a bad idea, what's the biggest positive
>    impact technical project, in your opinion?)

Salsa as the one and only platform of hosting our packaging, with only
ONE way of doing so in git, not half a dozen, followed by "git push ==
upload" I mentioned elsewhere.

And less "I'm the package maintainer, this is my castle, go away" and
more "This is how the majority does it, you follow, the benefit of it
being one way, not a dozen different, outweight some personal
preferences".

--
bye, Joerg

Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Stefano Zacchiroli
On Sat, Mar 30, 2019 at 11:38:43PM +0100, Joerg Jaspert wrote:
> And less "I'm the package maintainer, this is my castle, go away" and
> more "This is how the majority does it, you follow, the benefit of it
> being one way, not a dozen different, outweight some personal
> preferences".

Let's cut to the chase of this.

Statement: every Debian package must be maintained in Git on salsa and
every Debian Developer with upload rights to the archive should have
commit/push right to every packaging repository on salsa.

DPL candidates: do you agree with this statement?
If so, what will be your approach to make this a reality?

(I'm putting on the side, on purpose, the problem of different workflows
that Joerg has highlighted. Not because it's not a real problem, but
because I think it's a distraction to discussing/fixing the more
substantial problem of access rights and package ownership.)

Cheers
--
Stefano Zacchiroli . [hidden email] . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Joerg Jaspert
On 15358 March 1977, Stefano Zacchiroli wrote:

>> And less "I'm the package maintainer, this is my castle, go away" and
>> more "This is how the majority does it, you follow, the benefit of it
>> being one way, not a dozen different, outweight some personal
>> preferences".
> Let's cut to the chase of this.

> Statement: every Debian package must be maintained in Git on salsa and
> every Debian Developer with upload rights to the archive should have
> commit/push right to every packaging repository on salsa.

> DPL candidates: do you agree with this statement?

Well, you took it from one of my mails, so it is mostly what I said, so
yeah. Concepts like LowThresholdNMU are nice, but the wrong way around.

> If so, what will be your approach to make this a reality?

I think the DPL can (try to) start and steer discussions the right way.
In the end something that drastic will need a project decision on it,
either by everyone just doing it (highly unlikely given our project) or
a GR.

It's also possible that something this big needs more resources thrown
at (like scaling salsa or the ci around it), in that a DPL can obviously
use the assets available in the best possible way. Be that with sprints,
throwing hardware at it, whatever.

--
bye, Joerg

Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Jonathan Carter (highvoltage)-2
In reply to this post by Stefano Zacchiroli
Hi Zack

On 2019/03/31 09:39, Stefano Zacchiroli wrote:

> On Sat, Mar 30, 2019 at 11:38:43PM +0100, Joerg Jaspert wrote:
>> And less "I'm the package maintainer, this is my castle, go away" and
>> more "This is how the majority does it, you follow, the benefit of it
>> being one way, not a dozen different, outweight some personal
>> preferences".
>
> Let's cut to the chase of this.
>
> Statement: every Debian package must be maintained in Git on salsa and
> every Debian Developer with upload rights to the archive should have
> commit/push right to every packaging repository on salsa.
>
> DPL candidates: do you agree with this statement?

In general, I think so. I'm unsure about the first "must" though, I tend
to like that we're not so rigid and inflexible in our policies that we
can't cater for a few exceptions. For example, I could understand that
packagers of a VCS system would want to host their work in such a VCS,
for example...

"""
$ debcheckout -d bzr
type bzr
url https://code.launchpad.net/~debian-bazaar/debian/sid/bzr/unstable
"""

Having said that, all the other major VCS systems already seem to be
either in salsa or in another git repository.

I'm not fundamentally against that being a "must", but we should just be
aware that there might be some use cases that we'll end up sacrificing
in order to make such a unification of source control hosting possible.

> If so, what will be your approach to make this a reality?

Well, if we'd want to enforce this, it would ultimately have to get into
policy somehow.

DEP14 (https://dep-team.pages.debian.net/deps/dep14/) predates salsa so
doesn't mention it, but that already had quite a lot of thought go into
it, and if that would be expanded to include bits about salsa hosting,
then you get what you mentioned above plus the workflow parts from below
(which are already used on salsa by a number of projects).

I also do think that "every Debian package /should/ be maintained in Git
on salsa" would be easier to accept project-wide than "every Debian
package /must/ be maintained in Git on salsa". I would perhaps ask the
proposer of such a statement to consider whether it might be worth while
taking the smaller step first, and then in the future revisit it to
change it to the stronger statement when the community at large have had
more time to adapt.

> (I'm putting on the side, on purpose, the problem of different workflows
> that Joerg has highlighted. Not because it's not a real problem, but
> because I think it's a distraction to discussing/fixing the more
> substantial problem of access rights and package ownership.)

ack.

-Jonathan

--
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Stefano Zacchiroli
In reply to this post by Joerg Jaspert
On Sun, Mar 31, 2019 at 10:23:29AM +0200, Joerg Jaspert wrote:
> On 15358 March 1977, Stefano Zacchiroli wrote:
> > Statement: every Debian package must be maintained in Git on salsa and
> > every Debian Developer with upload rights to the archive should have
> > commit/push right to every packaging repository on salsa.
>
> Well, you took it from one of my mails, so it is mostly what I said, so
> yeah. Concepts like LowThresholdNMU are nice, but the wrong way around.

The big difference is the "must": I'm suggesting that no package should
be in the archive if it isn't Git-maintained on salsa in a repo writable
by all DDs.  So, let me insist: do you agree with that (specific version
of the) statement or not?

> I think the DPL can (try to) start and steer discussions the right way.
> In the end something that drastic will need a project decision on it,
> either by everyone just doing it (highly unlikely given our project) or
> a GR.

I'm sorry, but there are so many hypothethicals here that I still have
no idea of what you, as a DPL, will do to make us closer to the net
goal. Will you start a discussion on this or not? Will you start a GR on
this or not?

Cheers
--
Stefano Zacchiroli . [hidden email] . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Stefano Zacchiroli
In reply to this post by Jonathan Carter (highvoltage)-2
On Sun, Mar 31, 2019 at 10:42:10AM +0200, Jonathan Carter wrote:
> In general, I think so. I'm unsure about the first "must" though, I tend
> to like that we're not so rigid and inflexible in our policies that we
> can't cater for a few exceptions. For example, I could understand that
> packagers of a VCS system would want to host their work in such a VCS,
> for example...
[...]
> I'm not fundamentally against that being a "must", but we should just be
> aware that there might be some use cases that we'll end up sacrificing
> in order to make such a unification of source control hosting possible.

I agree with your analysis here: there is a clear trade-off between
flexibility in package maintenance practices and uniformity.

I know well where I'm placed on that trade-off: I'd take uniformity
every day. I'm convinced Debian's inability to impose one way of
maintaining packages is holding us back in our ability to implement (by
the means of semi-automation) archive-wide changes and is also setting
the bug for newcomers unreasonably high.

What I'm trying to determine with this sub-thread is which candidates,
if any, are willing to take a courageous stance on this matter and, if
so, how will they go about it.

For now, I'm understanding that you're more inclined than Ganneff to
take steps to uniform package maintenance practices, but at the same
time you want to retain some uniformity. So I'm still at loss at what
*concrete steps* you will take to increase uniformity throughout the
archive.

Cheers
--
Stefano Zacchiroli . [hidden email] . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Roberto C. Sánchez-2
In reply to this post by Jonathan Carter (highvoltage)-2
On Sun, Mar 31, 2019 at 10:42:10AM +0200, Jonathan Carter wrote:

> On 2019/03/31 09:39, Stefano Zacchiroli wrote:
> >
> > Statement: every Debian package must be maintained in Git on salsa and
> > every Debian Developer with upload rights to the archive should have
> > commit/push right to every packaging repository on salsa.
> >
> > DPL candidates: do you agree with this statement?
>
> In general, I think so. I'm unsure about the first "must" though, I tend
> to like that we're not so rigid and inflexible in our policies that we
> can't cater for a few exceptions. For example, I could understand that
> packagers of a VCS system would want to host their work in such a VCS,
> for example...
>
[SNIP]
>
> I'm not fundamentally against that being a "must", but we should just be
> aware that there might be some use cases that we'll end up sacrificing
> in order to make such a unification of source control hosting possible.
>
Some of the packages I am involved in maintaining for Debian live in
upstream Git repositories (and I do my associated packaging work and
build packages for upload from those same repositories).

I suppose requiring that they be pull-mirrored to Salsa might make
sense, but requiring that the primary place of development for Debian
packaging actually be in Salsa would present an obstacle for some of my
current packages.  Of course, that would mean that direct commits to the
Salsa project in such an instance would be problematic.

It would not surprise me if such a requirement were to cause some
upstream developers to give up on being involved in the Debian packaging
of their projects rather than deal with the hassle.  Perhaps other
interested parties not involved with upstream might come along and
maintain these packages.  In some cases that may be no great loss, but
there are enough upstream developers who are frustrated by Debian
policies it would seem to be better to be more accommodating, not less.

Regards,

-Roberto

--
Roberto C. Sánchez

Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Jonathan Carter (highvoltage)-2
In reply to this post by Stefano Zacchiroli
Hi Zack

On 2019/03/31 12:07, Stefano Zacchiroli wrote:

> I know well where I'm placed on that trade-off: I'd take uniformity
> every day. I'm convinced Debian's inability to impose one way of
> maintaining packages is holding us back in our ability to implement (by
> the means of semi-automation) archive-wide changes and is also setting
> the bug for newcomers unreasonably high.
>
> What I'm trying to determine with this sub-thread is which candidates,
> if any, are willing to take a courageous stance on this matter and, if
> so, how will they go about it.
>
> For now, I'm understanding that you're more inclined than Ganneff to
> take steps to uniform package maintenance practices, but at the same
> time you want to retain some uniformity. So I'm still at loss at what
> *concrete steps* you will take to increase uniformity throughout the
> archive.

I'm assuming that you made a small mistake in the paragraph above and
that you meant s/retain some uniformity/retain some flexibility/.

In terms of specifically committing to actions to drive the original
statement that you posted, I believe that would be somewhat
irresponsible. As DPL I don't want to impose agendas that doesn't yet
have a form of wide-spread consensus. This doesn't mean that everyone
has to agree, it also doesn't mean that we have to discuss it for weeks,
but as DPL, it would be my goal to enact on the wishes of the project
members, and I accept that with any progress there will be some people
that will be unhappy about some things some times. As a project, we all
have to learn that we won't always get our way and that that's ok. And
for those who do have objections to a process, I want to formally log
those so that they're acknowledged and so that we can plan mitigations
for those scenarios and ultimately, avoid looping through the same
conversations over and over on debian-devel without getting anywhere. I
know it may seem that I'm steering a bit off-topic here, but I'm not, my
ways of working as DPL is an important consideration in answering this
question.

So, in terms of your original two questions, I do feel that I originally
answered them sufficiently: my stance is basically that I'm not in a
position right now to commit to a solid approach in making that
statement a reality until I have the backing of our project members to
drive such a project.

And I believe it's reasonable to hear out all the concerns. Just today
on #debian-devel (I've redacted the log just to keep it on point, times
are UTC+2):

"""
10:25 < jcristau> eww @ "every DD gets to push to every packaging repo"
10:26 < dwfreed> -1
<redacted>
10:42 < jcristau> i don't trust a thousand people with my packages, and
i don't trust myself with everybody else's packages
11:03 < Ganneff> jcristau: scary thought, yes, but i think its the long
term goal to make us better. and to get large scale changes easier.
also, having such rights dont mean just going around randomly and
abusing them.
11:03 < jcristau> well if i don't need certain permissions i'd rather
not have them
11:04 < Ganneff> i can also imagine a way where one does not have it all
the time, but it is *easy* to get. thats "impementation detail".
11:05 < Ganneff> "found a bug in tons of packages, all point to the same
one line fix? be able to commit it everywhere and have it uploaded
WITHOUT weeks of patches send and ignored and whatnot"
11:09 < jcristau> a bug in tons of packages with the same one line fix
sounds like opportunity for rethinking how it's done to not need tons of
patches :)
"""

I'm not going to unpack every detail about the discussion above, but
there are certainly details to work through and consider. Having a
system where every DD has access to every git repository, and if we get
to a point where uploading a package becomes as simple as pushing to the
git repository, it can be a severe shock to a bunch of workflows and it
will surely need some cultural changes too.

So, having said all the above, I'm not against the idea :)

Also, the question you asked in this mail is a bit different than the
ones in your original. So, in terms of concrete steps to making this a
reality, I'll put together a small roadmap right here. Obviously it's
slightly hypothetical, we don't know who will be DPL yet, and you're
kind of putting me on the spot here, so with some more time to think
about it and having more feedback, details could obviously change, but
with all of that disclaimer out of the way, I think it might answer your
question:

1. DEP14 is still in draft, which is actually great because it means it
can be updated to reflect that we now use salsa.debian.org as our
standard version control repository location. I wouldn't drive those
changes unilaterally, I would make contact with Raphael who's marked as
the driver of that DEP, and ask if we can work together in making those
modifications and getting it to a final release state. I think that,
since many packages are already using a DEP14 layout and because it
hasn't brought up any problems yet, it shouldn't be too controversial
getting this DEP to a final stage.

2. Find some way to declare that a package is DEP14 compliant, maybe in
the control file, maybe just somewhere in the git repository, I don't
particularly care about the implementation, but since DEPs are opt-in,
it would be great to be able to track project-wide how many package
repositories are following it and to track momentum. It would need some
active promotion in the project.

3. The process above will be two-fold. It will help find edge cases that
can be fixed towards making that project policy, and it will get us some
good way in having that policy applied already. Additionally, when
something is already widely done it's easier to get applied in policy.
At that stage I think it could be very much uncontroversial and might
just have to go through a usual policy release cycle rather than
something as blunt as a GR.

That whole process might take a few months, or even as much as a whole
release cycle. I don't think it helps to push things too hard in Debian,
we tend to work better together when we make many small steps together
rather than having a few people try to make very hard pushes.

I know that I've conveniently left out the part about DDs having access
to all repositories above, but I think that's a detail that you might
have to be willing to give up on to make the rest of the above possible.
One might also argue that anyone already has access to change things by
submitting an MR. I know it's not quite the same thing, but sometimes
you have to make small sacrifices to a vision to drive the rest of it
forward.

-Jonathan

--
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Sam Hartman-3
In reply to this post by Stefano Zacchiroli
>>>>> "Stefano" == Stefano Zacchiroli <[hidden email]> writes:

    Stefano> On Sat, Mar 30, 2019 at 11:38:43PM +0100, Joerg Jaspert wrote:
    >> And less "I'm the package maintainer, this is my castle, go away"
    >> and more "This is how the majority does it, you follow, the
    >> benefit of it being one way, not a dozen different, outweight
    >> some personal preferences".

    Stefano> Let's cut to the chase of this.

    Stefano> Statement: every Debian package must be maintained in Git
    Stefano> on salsa and every Debian Developer with upload rights to
    Stefano> the archive should have commit/push right to every
    Stefano> packaging repository on salsa.

So, with my DPL candidate hat on, I absolutely agree that this is an important
discussion to have.  I think we've reached a point where we've discussed
enough of the issues that we can have a discussion around forming
consensus rather than a researchy discussion where we explore the
issues.

I plan on approaching this in a couple of phases.
I plan to reach out to salsa maintainers, DSA, and probably ftpmaster
(although it's not clear they have a direct need to be involved, it
seems important) and make sure I am framing the discussion well.

Then I'd start a discussion on -project or -devel; not 100% sure which
and try and guide that discussion to a consensus.
If one emerges, I'd call it.  It wouldn't be important to get to
implementation details, just a consensus on the overall direction (and
things like must vs should).
If that consensus can be called, I'd delegate the decision of coming up
with an implementation approach.  (Well, if the consensus is no we don't
want to do that, it might not require a delegation to implement the
status quo:-)


If we aren't going to reach a consensus I'd look into either proposing a
GR with multiple ballot options or delegating the decision to the TC.
TC vs GR would depend on whether the open issues seem like technical
ones clearly within the scope of the TC or non-technical policy.

I think asking the DPL candidates to state a position on this issue is
harmful.  I think I could be more effective in driving this discussion
if I don't state a personal opinion.  It's not the DPL's job to decide
issues like this: it's the DPL's job to lead the project in making these
decision.  I'd encourage you to think more carefully before asking DPL
candidates to strongly state things that aren't the DPL's business in
the future.

That said, I'll answer, because the question having been asked, being
equivocal is perhaps more harmful.
I want to stress that my goal would be to come to a decision, not to
implement my will.

I agree with the above statement.  Essential to my agreement is that you
say DDs should have push access not must have push access.  I'd say that
an MR on salsa must be a reasonable way to contribute a patch, and that
DDs should have push access.  During the discussion, we might decide
that DDs must have push access, but there are more open issues there
including the one Roberto brought up.

--Sam

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Stefano Zacchiroli
Hi Sam, thanks for your detailed follow-up, which fully answer my
question.

Just a minor point on this:

On Sun, Mar 31, 2019 at 07:52:46AM -0400, Sam Hartman wrote:
> I'd encourage you to think more carefully before asking DPL candidates
> to strongly state things that aren't the DPL's business in the future.

I respectfully disagree.  While it's not DPL's responsibility to
implement (and maybe even drive) any specific technical/workflow change
in the project, knowing what the DPL *thinks* about matters like this
one is a fundamental element when deciding whom to vote for. That is
certainly the case for my vote, but I suspect I'm not alone.

As I see it, we decide which candidates to vote for based on two main
elements: general vision and specific program for the upcoming DPL term.
The question I've asked helps, I believe, in better understanding the
technical/workflow vision for Debian of each candidate.

Cheers
--
Stefano Zacchiroli . [hidden email] . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Joerg Jaspert
In reply to this post by Stefano Zacchiroli
On 15358 March 1977, Stefano Zacchiroli wrote:

>> > Statement: every Debian package must be maintained in Git on salsa and
>> > every Debian Developer with upload rights to the archive should have
>> > commit/push right to every packaging repository on salsa.
>> Well, you took it from one of my mails, so it is mostly what I said, so
>> yeah. Concepts like LowThresholdNMU are nice, but the wrong way around.
> The big difference is the "must": I'm suggesting that no package should
> be in the archive if it isn't Git-maintained on salsa in a repo writable
> by all DDs.  So, let me insist: do you agree with that (specific version
> of the) statement or not?

Yes.

>> I think the DPL can (try to) start and steer discussions the right way.
>> In the end something that drastic will need a project decision on it,
>> either by everyone just doing it (highly unlikely given our project) or
>> a GR.

> I'm sorry, but there are so many hypothethicals here that I still have
> no idea of what you, as a DPL, will do to make us closer to the net
> goal. Will you start a discussion on this or not? Will you start a GR on
> this or not?

More than what we have at -vote just now, I will start a discussion on
-devel, yes. GR or not depends on the way that discussion will run. It
may show more hurdles than I currently can think of and turn out to make
no sense now to run a GR on it. OTOH it can show lots of support and
mostly small issues that are simple to solve, then a GR is good to have
and I will start one.

--
bye, Joerg

Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Joerg Jaspert
In reply to this post by Stefano Zacchiroli
On 15358 March 1977, Stefano Zacchiroli wrote:

>> I'm not fundamentally against that being a "must", but we should just be
>> aware that there might be some use cases that we'll end up sacrificing
>> in order to make such a unification of source control hosting possible.
> I agree with your analysis here: there is a clear trade-off between
> flexibility in package maintenance practices and uniformity.

Yes.

> I know well where I'm placed on that trade-off: I'd take uniformity
> every day. I'm convinced Debian's inability to impose one way of
> maintaining packages is holding us back in our ability to implement (by
> the means of semi-automation) archive-wide changes and is also setting
> the bug for newcomers unreasonably high.

I have been on the side of "we are fine, you need to learn stuff, go and
do it". I am still on that, but much moving to "It ought to be enough to
learn one way and style, not a trillion different little ones".

This is scary in many ways, starting with "Oh gosh, 1k other people have
access to MY packages?" and "Uh what, I am able to modify all them other
30k packages, why do you trust me with that" and is entirely different
to what we do now (mostly, collab maint exists, I know).

> What I'm trying to determine with this sub-thread is which candidates,
> if any, are willing to take a courageous stance on this matter and, if
> so, how will they go about it.
> For now, I'm understanding that you're more inclined than Ganneff to
> take steps to uniform package maintenance practices, but at the same
> time you want to retain some uniformity. So I'm still at loss at what
> *concrete steps* you will take to increase uniformity throughout the
> archive.

I know I've not given exact steps on how to go. Discussion, possible GR.
That is vague, I understand. It is too broad a thing to nicely formulate
something now and stick with it. But I wouldn't say I am not prepared to
take steps to uniform stuff. Though I can list some actionable items, if
that makes it feel more real.

First off it needs to get discussed at a proper venue, -devel or
-project, not -vote. It also needs to have talks with DSA and salsa
maintainers, as it will mean a noticable load increase for that service
which may mean a change of the way it is setup (split over machines).
If that all works out positively, it needs -policy involved, as that
document needs to have paragraphs talking about it.
And then it will end up a GR, presenting the worked out solution and
policy change to the developers and let them decide for or against it.

And working that out will take time. While its simple to state "It all
must be there", there are various exception to the rule to be
considered, as usual. And get into it...

--
bye, Joerg

Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Jonathan Carter (highvoltage)-2
In reply to this post by Stefano Zacchiroli
On 2019/03/31 14:12, Stefano Zacchiroli wrote:

> I respectfully disagree.  While it's not DPL's responsibility to
> implement (and maybe even drive) any specific technical/workflow change
> in the project, knowing what the DPL *thinks* about matters like this
> one is a fundamental element when deciding whom to vote for. That is
> certainly the case for my vote, but I suspect I'm not alone.
>
> As I see it, we decide which candidates to vote for based on two main
> elements: general vision and specific program for the upcoming DPL term.
> The question I've asked helps, I believe, in better understanding the
> technical/workflow vision for Debian of each candidate.

I tend to agree with that. Any question is fair game (within reasonable
limits of course, we don't want something dumb that goes against our CoC
and other values), it's up to the candidate how they want to answer it,
or if they even want to answer it at all.

-Jonathan

--
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Sam Hartman-3
In reply to this post by Stefano Zacchiroli
>>>>> "Stefano" == Stefano Zacchiroli <[hidden email]> writes:

    Stefano> I respectfully disagree.  While it's not DPL's
    Stefano> responsibility to implement (and maybe even drive) any
    Stefano> specific technical/workflow change in the project, knowing
    Stefano> what the DPL *thinks* about matters like this one is a
    Stefano> fundamental element when deciding whom to vote for. That is
    Stefano> certainly the case for my vote, but I suspect I'm not
    Stefano> alone.

I'm hesitant to reply further.  However, I feel passionate about
respecting a diversity of opinions, and I'm concerned that the approach
you take above can lead the project away from respecting that diversity.
I'd like to explain why; I'm not trying to convince you to change your
mind, but I think this is important to understanding who I am and how I
think.



I hope people will vote for me because I can get stuff done, because I
care about avoiding unnecessary pain, and because they agree with my
thoughts about what areas we should focus on, and within the scope of
things that are DPL matters, because they agree with how I'd approach
them.

Assuming we agree a question is important to answer, and assuming we
agree that respecting the wishes of the project is important rather than
just forcing a decision on people, my personal beliefs take a back seat.
If I'm good at getting the project to that decision, I am quite likely a
better choice than someone who agrees more closely with your preferred
position but who isn't going to be effective at getting a decision and
respecting the project wishes.

going too far down the path of voting for people based on whether they
agree with you in areas that are not related to doing the job rather
than on whether they can do the job well can lead to divisive splits and
lack of diversity.  I'd prefer not to see that here.

--Sam

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Russ Allbery-2
In reply to this post by Roberto C. Sánchez-2
Roberto C. Sánchez <[hidden email]> writes:

> I suppose requiring that they be pull-mirrored to Salsa might make
> sense, but requiring that the primary place of development for Debian
> packaging actually be in Salsa would present an obstacle for some of my
> current packages.  Of course, that would mean that direct commits to the
> Salsa project in such an instance would be problematic.

One of the great things about Git is that there's really no such thing as
a "primary place of development" since every clone of the repository is
equal and it's nearly trivial to push a repository to multiple remotes.  I
suppose it could be a statement about process, but if we fleshed out the
idea some more, I suspect the most it would mean is that maintainers have
some responsibility to review PRs on Salsa (at least to the level that
they are responsible for looking at minor bug reports in the BTS), which
doesn't seem too unreasonable or onerous.

We may want to do some work on the notification process based on some past
threads, unless that's already been sorted out.  I've been surprised a few
times by discovering PRs or merged diffs for packages under the Debian
free-for-all-area because I hadn't figured out the right way to subscribe
to email notifications for such things.  (The surprise was pleasant, to be
clear, and I have no objections to the process; I just accidentally
uploaded one package without those fixes because I didn't realize they
existed and only found out after attempting to push my local repository.)

I keep all of my work on my own Git server for a variety of reasons, but
also push all upstream work to GitHub and much Debian work to Salsa, and
would have no objections to pushing more Debian work to Salsa.  Git isn't
great at handling multiple remotes out of the box, but I wrote one bit of
software (that I'm pretty close to releasing) to help make that easier,
and I'm sure more could be done.  It's already 90% of the way to being
automated, at which point it's essentially trivial to replicate the Git
repository to one more place.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Roberto C. Sánchez-2
On Sun, Mar 31, 2019 at 03:47:26PM -0700, Russ Allbery wrote:

> Roberto C. Sánchez <[hidden email]> writes:
>
> > I suppose requiring that they be pull-mirrored to Salsa might make
> > sense, but requiring that the primary place of development for Debian
> > packaging actually be in Salsa would present an obstacle for some of my
> > current packages.  Of course, that would mean that direct commits to the
> > Salsa project in such an instance would be problematic.
>
> One of the great things about Git is that there's really no such thing as
> a "primary place of development" since every clone of the repository is
> equal and it's nearly trivial to push a repository to multiple remotes.  I
> suppose it could be a statement about process, but if we fleshed out the
> idea some more, I suspect the most it would mean is that maintainers have
> some responsibility to review PRs on Salsa (at least to the level that
> they are responsible for looking at minor bug reports in the BTS), which
> doesn't seem too unreasonable or onerous.
>
I agree with what you are saying here.  However, I am concerned that the
"push == automatic package upload" idea may be a step too far in some
cases.

Regards,

-Roberto

--
Roberto C. Sánchez

Reply | Threaded
Open this post in threaded view
|

Re: Bikeshedding

Russ Allbery-2
Roberto C. Sánchez <[hidden email]> writes:
> On Sun, Mar 31, 2019 at 03:47:26PM -0700, Russ Allbery wrote:

>> One of the great things about Git is that there's really no such thing
>> as a "primary place of development" since every clone of the repository
>> is equal and it's nearly trivial to push a repository to multiple
>> remotes.  I suppose it could be a statement about process, but if we
>> fleshed out the idea some more, I suspect the most it would mean is
>> that maintainers have some responsibility to review PRs on Salsa (at
>> least to the level that they are responsible for looking at minor bug
>> reports in the BTS), which doesn't seem too unreasonable or onerous.

> I agree with what you are saying here.  However, I am concerned that the
> "push == automatic package upload" idea may be a step too far in some
> cases.

I assume this would only happen if you push a signed tag.  I wouldn't want
every random commit I push to immediately be uploaded.  Constantly
releasable master branch is a nice goal, but I can't say that I always
follow it 100% nor want to be forced to.  At that point, it just means
replacing some dput or dgit upload rune with some git push rune.  (Well,
and dedicating some tag space, but hopefully most people who are using Git
for packaging are already tagging.)

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

123