search

maemo-leste / bugtracker

Issue tracking repository
62 stars 3 forks source link

Create collaboration/policy document #310

Open MerlijnWajer opened 4 years ago

MerlijnWajer commented 4 years ago

I've been thinking about this for a bit, and I think it would be helpful for all devs to have a set of guidelines on what repos can we push changes (to maemo/* and master branches) without discussion, and what repos we should have discussion (or maybe work via PR?). This can hopefully prevent confusion about "what is the right or normal thing to do", minimise friction and help us focus instead on what matters, without slowing any of us down in our development. (I really don't want to switch to a Pull-Request-For-Everything-For-Every-Package kind of thing currently)

So -- maybe can we solve this with a simple set of directions/rules/etc.

A potential separation could be 'core' hildon repositories and some drivers (like powervr), and then there's everything else (for which we can mostly freely just make changes as long as they're not too insane). But I think we'd need to explicitly mention such core repositories.

For example, we could say that hildon-core is:

and any other direct dependencies (e.g. libgofono for connui)

And then some driver relates packages would be for example:

Additionally, I think we probably want to declare a (single) 'maintainer' for such packages (one maintainer per package). Maintainers could perhaps (if they decide to) push bigger changes without consulting with others. @spinal84 could clearly be a maintainer for N900 PowerVR packages. @freemangordon is probably currently the point of contact for most/all hildon packages. I've done lots of random hacking, but maybe could be the point of contact for stuff like ke-recv. Perhaps some of the droid and pine stuff, too.

So perhaps for the recent hildon-input-method-framework change, we could have had a PR there with @spinal84 's changes, and then work from there.

The above is only a suggestion, and I'm hoping for feedback from all. If we agree, I can distil all of this into a document on the Wiki.

MerlijnWajer commented 4 years ago

@freemangordon and @spinal84 - let's see if we can settle on a procedure that's acceptable for all, so we don't need to butt our heads and instead work on providing an awesome mobile OS for all. :)

eloydegen commented 4 years ago

Not really a technical policy, but I think it would be a good idea to adopt something like this: https://www.contributor-covenant.org/

spinal84 commented 4 years ago

I agree whatever you propose, @MerlijnWajer.

I just don't want to waste time on long discussions for trivial changes. It's counterproductive. I still didn't get what was the point of the discussion about bugfix change to hildon-input-method-framework @freemangordon initiated. He didn't propose better option. He just wasted my time on pointless doubts. That time I could spend on fixing another error or implementing a new feature. We have a lot of work pending - just take a look at bugzilla. Trivial things are not fixed for months and years. Please, correct me if I am wrong.

If someone wants to take a leadership on a package development, I'm all for it. The personal responsibility for individual packages is what we really mostly lack. The section "Maintainer" in debian/control file is a good starting point. Of course adding/changing the maintainer should be done after someone makes significant changes to the package (not to debian directory, not warnings fix, but the sources). That way we can have some guarantees that this man is somehow aware of how the package is functioning.

MerlijnWajer commented 4 years ago

Some discussions may seem a waste of time for trivial changes to you, but there may be more to it than some of us might initially believe. I'm sure @freemangordon has good reasons to question specific changes and proper discussion can be warranted even though a potential solution seems simple. It might also simply be a different way of looking at things: we might at some point want to support N810 (I'm not too hopeful, but others might be) so going out of our way not break it might make sense. BTW: I don't want to turn this ticket into a "Let's rehash this h-i-m ticket" (and I'm glad we currently have something working on the droid4), but I just wanted to clarify that.

I think the request for a discussion on how to proceed in that case is obviously part of the reason another solution was not just 'put forward', since that might again cut discussion short.

So where do we log the maintainer of a package? The debian/control file would be the most obvious place, but we can also start with a wiki. And what do we do for packages that don't have clear maintainers (and are non-core; we probably just want "dedicated maintainers" for core packages)?

I would argue that if a debian/control file doesn't list any of "us" (anyone involved in Maemo Leste), we should probably change it. There's no point in listing old Nokia employees as maintainer for those packages, right?

parazyd commented 4 years ago

Following up on this, we need to go through our repositories and define both software/code and the debian package maintainers.

The maintainer of the debian package should indeed be listed in debian/control, but it is not a place to reflect the actual maintainer of the code in question. For the actual code, I propose we have a page on https://leste.maemo.org wiki and use it to our advance.

I will make a stub page soon and see if we can work from there.

parazyd commented 4 years ago

I added an example of how it would look like here: https://leste.maemo.org/Development/Maintainers#Maemo_Leste_software_maintainers

Please note that it does not reflect the current maintenance situtation because I am not aware of the correct maintainers yet. This is a placeholder and will be filled in properly.

This would serve as a reference point to find who maintains certain software.