Mail Archives: geda-user/2015/08/23/09:46:25
Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com] wrote:
> > Would it help if I host git repos and hand out commit access to
> > interested people?
>
> I feared this. People see a tool to deal better with forks
I think you misunderstood my mail. "repos" refers to one repo per
component, not one repo per person per component. The motivation
is to gather efforts.
> Forks are the wrong way. As one can easily observe in the public
> repo, they almost halted official development.
I view this more pragmatically. I consider a "fork" to be nothing but
a series of changes based on some state in the project history.
These changes, individually or the whole set, are either fit for
inclusion into the project or they are not. If they are not, and
noone has time or interest to work on making them fit for inclusion,
then they remain experimental developments. Please know that this is
perfectly fine, and just as official development as any other
development within the project.
When people are working in their spare time others do not get to
dictate what should be worked on. At the most, one can provide a
wishlist, but one doesn't get to complain if random noise comes out.
If someone has created an experimental development and left it at
that, and *someone else* is interested in having this development
included into the project, then they (someone else) have the
responsible to make that happen. If they don't want to or are unable
to contribute the neccessary fitness effort then it will not happen.
And that is fine too, but noone is allowed to disrespect the effort
that has already been spent.
> they consider gEDA to be mostly dead, because there's no visible
> development and newer developments also don't get into Linux
> distributions.
Yes, I know this phenomenon well. Maintaining a widespread open
source project taught me quite a bit about the pure consumer
attitude of open source users and distribution package maintainers.
> Another reason against forks is lack of collaboration, which I'll
> try to explain in a minute to Igor2.
Team work needs a goal. gEDA hasn't set many big goals at the moment,
so there's not much team work. I don't think that's a bad thing, and
in particular I would never dare suggest that this has any bearing on
what happens in the future.
> > I think the branch ignore function should use a combination of
> > one remote URL (NB! git: vs. http: vs. https:) and one branch
> > name, rather than a commit hash, because the commit could be in
> > many branches and only one of them should be ignored.
>
> That's how it actually behaves:
I'm afraid you misunderstood here too.
> it doesn't ignore single commits, but only branches, if the last
> commit on a branch matches the ignored commit hash.
I understood, and I disagree with this design.
> It's the hash, because if a branch in a fork receives additional
> commits, the branch name is still the same; filtering by branch
> name whould ignore these new commits.
I think this is desirable.
> Filtering by hash makes these updated branches appear again, so
> they get noticed.
I think this is undesirable.
I of course realise that you want a different functionality than I,
I just mentioned that I would prefer the other one.
//Peter
- Raw text -