Re: [arch-dev-public] Proposal for a new organisation structure
On 3/6/19 2:39 pm, Christian Rebischke via arch-dev-public wrote: > 3. I don't like that devs and TUs live aside each other instead of > finally realizing themselves as community or group. The TUs are set up as an independent organisation with their own bylaws. Many of those bylaws were implemented to keep independence from the developer team. Saying that, almost all developers have been a Trusted User, and there is a decent overlap currently. I mostly see this as a responsibility divide. > I think the > community as itself would work much better if we would have user-access > based package repositories and just 'maintainers', instead of this > dev/TU split. I agree that the distinction between [extra] and [community] is rather limited. I think we need a better definition of what [extra] is, and move packages that don't fit that definition out of [extra] and into [community] where both devs and TUs can maintain them. Or even merge those two repos. >> As Gaetan already mentioned, the process is clear: somebody suggests a >> new developer and we discuss until a consensus is reached. Feel free to >> document that somewhere in our wiki if you think it needs to be >> documented. If you have specific concerns with that process, feel free >> to share them. However, I do not think anybody in the dev team ever had >> any objections against that procedure. > > What interests me is why is this whole process not transparent and > public? I mean we discuss adding new TUs publicly. Of course this > dicussion comes with all its good and bad parts, but atleast it's > transparent and people get a reason why they are not elected. You are very much overthinking what goes on when deciding on a new developer. "Electing" a developer is very different than electing a TU. People given developer positions have probably been around for years and are already doing the job before they get formally offered it. So it is a case of someone saying "this person should be a developer" and the rest going "OK". There is usually no discussion, because the candidate is well known already, and has obviously been doing a good job to even be nominated. Having TU style discussions on the suitability of a candidate makes no sense in that situation. Allan
Re: [arch-dev-public] Proposal for a new organisation structure
On Sun, Jun 02, 2019 at 12:38:24AM -0400, Public mailing list for Arch Linux development wrote: > Dear Christian, > > Thank you for your email. > > I do not share your point of view that the organization is chaotic. You > successfully explained the three roles and each of its duties within two > or three clear sentences. We could certainly have a more fine-grained > hierarchy but our team is not very big and I personally do not think the > benefits would outweigh the extra administrative work in the long run. > > Do you have any concrete evidence that adding more bureaucracy would > benefit the project? Any evidence that our current organizational > structure prevents people from contributing (which you seemed to imply > with your statement above)? Well, my proposal was to remove bureaucracy, not to add more bureaucracy. Here are various issues that I had in the past: 1. I am waiting since weeks for a separate section for legal related content in our dev wiki for adding the AUR takedown request answer template. This template was created by awesome team work and I think it would be sad if it would be just gone. Furthermore people said that it would be a good idea to have it somewhere for future takedown requests. 2. At the moment it's difficult to co-maintain packages between [extra] and [community]. A developer who wants to allow co-maintainership by TUs needs to move a package to [community]. In my opinion this step is unnecessary and leads to unnecessary communication and workflows. 3. I don't like that devs and TUs live aside each other instead of finally realizing themselves as community or group. I think the community as itself would work much better if we would have user-access based package repositories and just 'maintainers', instead of this dev/TU split. > As Gaetan already mentioned, the process is clear: somebody suggests a > new developer and we discuss until a consensus is reached. Feel free to > document that somewhere in our wiki if you think it needs to be > documented. If you have specific concerns with that process, feel free > to share them. However, I do not think anybody in the dev team ever had > any objections against that procedure. What interests me is why is this whole process not transparent and public? I mean we discuss adding new TUs publicly. Of course this dicussion comes with all its good and bad parts, but atleast it's transparent and people get a reason why they are not elected. I am a big fan of the 'people can change' attitude, but this only works if they know their mistakes. The only reason for private discussions seems to be 'personal bias'. Atleast thats what I think if I think about private elections or better selections of new devs. And personal bias should never a criteria to select or deny somebodys contribution, it should be based on technical questions. > The idea of having a separate repository for (most) proprietary sounds > sensible to me. > I have a few things to add regarding proprietary software, that we have discussed in IRC. It would be nice to have atleast a list somewhere with proprietary software and their license. I mean we can be glad, that the TU asked for adding vivaldi browser to community, what if he would have just added it? I guess it wouldn't be a problem, until somebody finds it or we get a take down request for the package. Therefore I wonder how many packages we may illegaly redistribute already? Maybe it would be useful to track such packages somehow and a separate repository would be a good starting point for this. > Is there any hidden suggestion here? Yes, a suggestion for user-isolated packages. This will be/can be achieved via the move to a git repository. > I am confused. You are saying we are mixing too many roles above and > suggesting to reduce the number of roles now? Well, I guess it's not possible to simplify all rules. But we could at least start with simplifying the role of package maintainers and start realizing us as one community not as two separate groups. > > It would be also nice to form an actual roadmap (yes.. I know.. we are > > not a company, but a roadmap or overview over all current projects > > inside of our community would be nice). This way it would be also easier > > to contribute for 'outsiders'. > > Does not sound like a bad idea to me. Feel free to create a draft. A kanboard does exist already for it, and I hope more will be discussed at meetups. signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal for a new organisation structure
Em junho 1, 2019 20:08 Christian Rebischke via arch-dev-public escreveu: DISCLAIMER: Sorry for the huge mail, I didn't thought it would get so long. If you feel attacked/angry or whatever about it, take a deep breath before you answer. I hope for a constructive discussion without personal attacks. Ok. Here we go. At the moment we have the following three Groups (If I miss something feel free to correct me): - Devs - Trusted Users - Support Staff The lines are not that clear cut, but in a general sense we have those 3. At least that's what's on our website, so I'll give you that. I'm a perfect example of why this is not always the case. These three groups have the following 'features' and tasks: - Devs: - Tasks: The developers care about [core] and [extra] repositories, they form a direction for the whole project 'arch linux' and they seem to have a veto-permission for TU decisions. Furthermore they have access on most infrastructure and they are maintaining/developing the core software like pacman. Some devs also care about trademarks, legal requests and finance or community events. Devs can also care about [community], if they are also a TU. Also, regarding what you said about veto, there's no such thing. Yes, devs *can* have a final say on stuff, but that's different from vetoing it. A veto, by definition, means no discussion at all. I don't recall ever some dev simply saying something wouldn't happen and no discussion regarding it. Also, common sense applies here (you can't get it on writing though). Regarding infrastructure, the devops team has access to the infrastructure, but that doesn't mean dev's have access by default. Yes, a lot of people on the devops team are dev's, but it's not a requirement, at all. I've applied to TU, to only then learn about the devops team. I would probably started contributing there first, instead of applying to TU if I learned about it sooner. By the way, this brings back the discussion about having a one stop page for contributions. - How to be a developer?: The developers will decide in a non public and secrete ritual who is worthy to be a developer. The process is unclear. There's no ritual. One of the things I did after becoming a dev was to go through arch-dev's archives. I didn't saw any arcane rituals or goat sacrifices. It's basically: Hey, let's promote X to dev? +1. Some discussion might ensue, but it's rare and I never saw one promotion that didn't go through in these years I've been dev. - Trusted Users: I'll skip, you described this accurately. - Support Staff: - Tasks: They do various tasks like infrastructure administration, wiki administration, bug wrangling, software contribution, forum moderators, security team, but they have no access to any repository. Just to point out that some staff have access to a lot of stuff. Even if it's not clear immediately. - How to be a support staff: It's unclear, mostly a new contributor just knows the right people and does the right thing at the right time and get somehow acknowledged by developers or TUs for their work. Mostly because staffers are doing the work nobody wants to. I have the uttermost respect for our bug wranglers, wiki, forums and other staff. Also, you didn't include in this our testers. 1. Simplified repositories Currently we have [core], [extra] and [community]. These three repositories are there, because they have grown to this structure over time. At the moment I don't see any real meaning for the split of [core] and [extra]. So one suggestion would be to either: - merge [extra] and [core] - or use [extra] for a new purpose, like for example a proprietary repository, for all proprietary software. (I know that this is not possible for all packages, because we have binary blobs in device drivers and kernel modules). You forgot to mention that [core] has mandatory testing, even if, it's not enforced by the tooling. 3. Organisation structure Depending on the repository access, we could reduce our organisation structure to just two groups: Devs and maintainers (a similar approach to big distributions like Debian). Devs could still have the 'superpower' for caring about infrastructure and legal/finance stuff and the group of trusted users and support staff would merge to one group of maintainers. With person-related access to package repositories we could tear down the whole repository structure to one, maybe two, repositories and we could give co-maintainership an actual meaning (permission to modify a foreign package). You're not account here for the bus factor. There's a reason why everyone can touch everyone's else packages. We're a volunteer based distro. Sometimes people can't handle stuff, but are still interested on the project. 4. More transparency At the moment the recruiting
Re: [arch-dev-public] bringing vivaldi browser to community
On 6/2/19 2:59 AM, Ike Devolder wrote:
> On Sat, 2019-06-01 at 22:11 -0400, Eli Schwartz via arch-dev-public
> wrote:
>> On 6/1/19 5:43 PM, Allan McRae via arch-dev-public wrote:
>>> On 2/6/19 1:53 am, Ike Devolder via arch-dev-public wrote:
On Sat, 2019-06-01 at 21:30 +1000, Allan McRae wrote:
> You don't seem to
> explain why you need to ask in your email.
Because it is proprietary and I explain that now there is a valid
reason compared to 3 years ago where there was practically no
difference between vivaldi, chromium and opera.
>>>
>>> Does the license allow us to have it in the repos? After a quick
>>> look,
>>> I'd say no.
>>
>> The license for the AUR package appears to be somehow extracted using
>> /usr/bin/strings from one of the binary files in the software
>> download.
>>
>> Assuming it's the same as the one here:
>> https://vivaldi.com/privacy/vivaldi-end-user-license-agreement/
>>
>> It's absolutely illegal to redistribute it. As per the pinned comment
>> on
>> the AUR package, it is also available and illegally redistributed as
>> a
>> repackaged pacman package here: https://repo.herecura.eu/
>> This should probably be removed too.
>>
>> Note: there are other proprietary packages shipped in the Arch repos,
>> but on the unusual occasion where we deem it fitting to provide such
>> software, we have written authorization from the rights-holders to do
>> so.
>> As far as I can tell, that is not the case here. If and when it is
>> the
>> case here, that permission can be added to the
>> /usr/share/licenses/${pkgname}/ directory of the vivaldi package in
>> the
>> AUR, to signify that the prebuilt packages are legally
>> redistributable,
>> either in personally hosted repos or [community].
>>
>> See the teamspeak3 package for an example implementation.
>> https://git.archlinux.org/svntogit/community.git/tree/trunk/PERMISSION.eml?h=packages/teamspeak3
>>
>> ...
>>
>> Just because we are not an FSDG distribution which prays at the altar
>> of
>> Richard Stallman doesn't mean licensing is some sort of silly joke
>> that
>> no one cares about.
>>
>> And I don't think it makes sense to say this matters less, if it's
>> being
>> distributed from someone's personal repo instead of from a multi-
>> member
>> organization.
>>
>
> If that's what it requires, I can get a written consent we can re-
> distribute vivaldi. I asked them before putting it in my personal repo,
> if I was allowed to do that.
Cool -- if you have that permission, then there's no reason not to put
it in the AUR package too, though. :)
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] Proposal for a new organisation structure
[2019-06-02 06:06:35 +0200] Christian Rebischke: > On Sat, Jun 01, 2019 at 04:10:45PM -1000, Public mailing list for Arch Linux > development wrote: > Thanks for your mail. I remember now that you have told me this some > months ago. This leads to a question: Why are these types of dicussions > not public? Our discussion some months ago was public, just like this one. Most discussions among devs are public. Some aren't because we feel certain sensitive topics are better discussed in an environment where nobody is afraid to speak their mind. That includes topics like the addition of new developers, although like Lukas said in most cases those solely contain positive support for the proposal. Again, to the best of my knowledge, all devs are very happy with this process and do not want to change it. > Well, that's point. I don't really think the current system works as it > could be. Why being happy with the current state of organisation if we > could achieve much more with a more simplified and more contributor > friendly model? Feel free to explain what does not currently work as best as it could, what could be simplified, what could be more contributor friendly, etc. If you discussed specific problems, we could all have a go at proposing solutions a little more realistic than overhauling our organisational structure... > If you and the others see no point in > changing the current structure this is totally fine, I just think it's > important to rethink processes from time over time. What I think is most wrong with your current and previous "proposals" is that you obviously don't understand how the present dev system works, yet you want to change it! Have some humility, man, and remember this system has worked for about a hundred devs and for over a decade. Cheers. -- Gaetan signature.asc Description: PGP signature
Re: [arch-dev-public] bringing vivaldi browser to community
On Sat, 2019-06-01 at 12:12 +0200, Ike Devolder wrote: > 3 years have passed since I first proposed to bring vivaldi into > community. Now there is a clear differentiation between what vivaldi > offers out-of-the box compared to other browsers. > > Vivaldi offers a ton of customisation features out of the box, and is > also able to just use the chrome/ium addons from the chrome webstore. > > Personally I'm using vivaldi as my main browser since somewhere in > 2015 > (shortly after the first beta was released) and the key features no > other browser currently offers are: > - webpanels > - quick commands > - tabtiling > - tabstacking > - tabbar positioning > > I'll bring it in the same way as with opera, where you have the > webbrowser + separate packge with libffmpeg.so to allow the playback > of > proprietary formats like mp4. As stated by some on IRC I could just have dropped in the repos and be done with it. No one would have complained I guess. But to be fair, I personally think you have the right to know I want to maintain a package for proprietary software. And if there is a consensus against it I will definatly not package the proprietary stoftware in our repos. And thanks to the constructive input I will make sure it is obvious we have the rights for redistribution. That was also mostly my goal, get input if I'm missing something or overlooked something before bringing it in. signature.asc Description: This is a digitally signed message part
Re: [arch-dev-public] GCC 9 removed from [testing]
On 02/06/2019 09.37, Bartłomiej Piotrowski via arch-dev-public wrote:
> On 26/05/2019 22.39, Eli Schwartz via arch-dev-public wrote:
>> Question: are you going to set up an archbuild alias on soyuz/dragon for
>> this, the way you did for gcc8? (Which reminds me, those archbuild
>> aliases still exist and could be deleted).
>
> I can create it, sure.
>
>> Also please bump the pkgrel for these packages as they were currently
>> just cp'ed from testing. dbscripts knows how to auto-reject uploaded
>> packages built with your repo, as long as the gcc/binutils/etc.
>> pkgver-pkgrel are new and thus do not appear in the archives.
>
> I think packages built againt GCC9 with bumped pkgrel would be rejected
> anyway ("package does not appear in repositories" or something along
> this) but yeah, I don't plan to touch it for the time being.
>
Ah, right, I forgot it also does some archive magic now. I guess I will
have to change it then… Likely today in the evening.
Re: [arch-dev-public] GCC 9 removed from [testing]
On 26/05/2019 22.39, Eli Schwartz via arch-dev-public wrote:
> Question: are you going to set up an archbuild alias on soyuz/dragon for
> this, the way you did for gcc8? (Which reminds me, those archbuild
> aliases still exist and could be deleted).
I can create it, sure.
> Also please bump the pkgrel for these packages as they were currently
> just cp'ed from testing. dbscripts knows how to auto-reject uploaded
> packages built with your repo, as long as the gcc/binutils/etc.
> pkgver-pkgrel are new and thus do not appear in the archives.
I think packages built againt GCC9 with bumped pkgrel would be rejected
anyway ("package does not appear in repositories" or something along
this) but yeah, I don't plan to touch it for the time being.
BP
Re: [arch-dev-public] bringing vivaldi browser to community
On Sat, 2019-06-01 at 22:11 -0400, Eli Schwartz via arch-dev-public
wrote:
> On 6/1/19 5:43 PM, Allan McRae via arch-dev-public wrote:
> > On 2/6/19 1:53 am, Ike Devolder via arch-dev-public wrote:
> > > On Sat, 2019-06-01 at 21:30 +1000, Allan McRae wrote:
> > > > You don't seem to
> > > > explain why you need to ask in your email.
> > >
> > > Because it is proprietary and I explain that now there is a valid
> > > reason compared to 3 years ago where there was practically no
> > > difference between vivaldi, chromium and opera.
> > >
> >
> > Does the license allow us to have it in the repos? After a quick
> > look,
> > I'd say no.
>
> The license for the AUR package appears to be somehow extracted using
> /usr/bin/strings from one of the binary files in the software
> download.
>
> Assuming it's the same as the one here:
> https://vivaldi.com/privacy/vivaldi-end-user-license-agreement/
>
> It's absolutely illegal to redistribute it. As per the pinned comment
> on
> the AUR package, it is also available and illegally redistributed as
> a
> repackaged pacman package here: https://repo.herecura.eu/
> This should probably be removed too.
>
> Note: there are other proprietary packages shipped in the Arch repos,
> but on the unusual occasion where we deem it fitting to provide such
> software, we have written authorization from the rights-holders to do
> so.
> As far as I can tell, that is not the case here. If and when it is
> the
> case here, that permission can be added to the
> /usr/share/licenses/${pkgname}/ directory of the vivaldi package in
> the
> AUR, to signify that the prebuilt packages are legally
> redistributable,
> either in personally hosted repos or [community].
>
> See the teamspeak3 package for an example implementation.
> https://git.archlinux.org/svntogit/community.git/tree/trunk/PERMISSION.eml?h=packages/teamspeak3
>
> ...
>
> Just because we are not an FSDG distribution which prays at the altar
> of
> Richard Stallman doesn't mean licensing is some sort of silly joke
> that
> no one cares about.
>
> And I don't think it makes sense to say this matters less, if it's
> being
> distributed from someone's personal repo instead of from a multi-
> member
> organization.
>
If that's what it requires, I can get a written consent we can re-
distribute vivaldi. I asked them before putting it in my personal repo,
if I was allowed to do that.
signature.asc
Description: This is a digitally signed message part
